From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5346C433DB for ; Tue, 30 Mar 2021 08:52:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 198FB61954 for ; Tue, 30 Mar 2021 08:52:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 198FB61954 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 63B136B0082; Tue, 30 Mar 2021 04:52:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C3246B0083; Tue, 30 Mar 2021 04:52:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43C3C6B0085; Tue, 30 Mar 2021 04:52:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id 242A36B0082 for ; Tue, 30 Mar 2021 04:52:47 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D68B2180AD81F for ; Tue, 30 Mar 2021 08:52:46 +0000 (UTC) X-FDA: 77975925132.36.682EDBD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 654BAA0009CD for ; Tue, 30 Mar 2021 08:52:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617094365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CpI+VCeNJT/ookoDx9elc7YUBCm5rqIvOw+8bExHEfQ=; b=C90XvgZtT8tt4p3us79Sxn7DaDDQpkXxbNlHv9TYcYGDAiQviicA7ygGmy7Mn00h+HwOln 9xuZb/eb4MxN4Y5ZgIxdKXB5hPW5lyeFF/Ay9ov3V5ZjJWI/LfDocVOAn0JM0SLZbCh5wP NpjGWNVaiMnKEf2Zqf/x3Kv7yijEz10= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-22-Z2yoihf0OueiN9p0CR_1ag-1; Tue, 30 Mar 2021 04:52:42 -0400 X-MC-Unique: Z2yoihf0OueiN9p0CR_1ag-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0F6DF81744F; Tue, 30 Mar 2021 08:52:41 +0000 (UTC) Received: from [10.36.114.210] (ovpn-114-210.ams2.redhat.com [10.36.114.210]) by smtp.corp.redhat.com (Postfix) with ESMTP id D9DE7607CB; Tue, 30 Mar 2021 08:52:38 +0000 (UTC) To: Hyunsoon Kim Cc: Andrew Morton , dseok.yi@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <1616995751-83180-1-git-send-email-h10.kim@samsung.com> <61a2df08-2681-34fc-3407-921993c8a1f5@redhat.com> <20210330014439.GA53009@ubuntu> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH] mm: add ___GFP_NOINIT flag which disables zeroing on alloc Message-ID: <928f43b1-54ab-e4e4-20f4-b7bd662eb4b1@redhat.com> Date: Tue, 30 Mar 2021 10:52:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <20210330014439.GA53009@ubuntu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 654BAA0009CD X-Stat-Signature: homeira976y99c5n4e5yke3w36fjujxx Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf23; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617094365-42815 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 30.03.21 03:44, Hyunsoon Kim wrote: > On Mon, Mar 29, 2021 at 12:53:48PM +0200, David Hildenbrand wrote: >> On 29.03.21 07:29, Hyunsoon Kim wrote: >>> This patch allows programmer to avoid zero initialization on page >>> allocation even when the kernel config "CONFIG_INIT_ON_ALLOC_DEFAULT" >>> is enabled. The configuration is made to prevent uninitialized >>> heap memory flaws, and Android has applied this for security and >>> deterministic execution times. Please refer to below. >>> >>> https://android-review.googlesource.com/c/kernel/common/+/1235132 >>> >>> However, there is a case that the zeroing page memory is unnecessary >>> when the page is used on specific purpose and will be zeroed >>> automatically by hardware that accesses the memory through DMA. >>> For instance, page allocation used for IP packet reception from Exyno= s >>> modem is solely used for packet reception. Although the page will be >>> freed eventually and reused for some other purpose, initialization at >>> that moment of reuse will be sufficient to avoid uninitialized heap >>> memory flaws. To support this kind of control, this patch creates new >>> gfp type called ___GFP_NOINIT, that allows no zeroing at the moment >>> of page allocation, called by many related APIs such as page_frag_all= oc, >>> alloc_pages, etc. >>> >>> Signed-off-by: Hyunsoon Kim >>> --- >>> include/linux/gfp.h | 2 ++ >>> include/linux/mm.h | 4 +++- >>> 2 files changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h >>> index 8572a14..4ddd947 100644 >>> --- a/include/linux/gfp.h >>> +++ b/include/linux/gfp.h >>> @@ -58,6 +58,8 @@ struct vm_area_struct; >>> #else >>> #define ___GFP_NOLOCKDEP 0 >>> #endif >>> +#define ___GFP_NOINIT 0x1000000u >>> + >>> /* If the above are modified, __GFP_BITS_SHIFT may need updating */ >>> /* >>> diff --git a/include/linux/mm.h b/include/linux/mm.h >>> index 8ba4342..06a23bb 100644 >>> --- a/include/linux/mm.h >>> +++ b/include/linux/mm.h >>> @@ -2907,7 +2907,9 @@ static inline void kernel_unpoison_pages(struct= page *page, int numpages) { } >>> DECLARE_STATIC_KEY_FALSE(init_on_alloc); >>> static inline bool want_init_on_alloc(gfp_t flags) >>> { >>> - if (static_branch_unlikely(&init_on_alloc)) >>> + if (flags & ___GFP_NOINIT) >>> + return false; >>> + else if (static_branch_unlikely(&init_on_alloc)) >>> return true; >>> return flags & __GFP_ZERO; >>> } >>> >> >> We discussed that in the past - whatever leaves the buddy shall be >> initialized. This is a security feature, not something random kernel m= odules >> should be able to hack around. >> >> We also discussed back then to allow other allocators to eventually be= able >> to optimize in the future if we are sure it really makes sense. Then, >> however, we need a new API that is not available to random modules, in= stead >> of exposing ___GFP_NOINIT to anybody out there in the system. >> >> Nacked-by: David Hildenbrand >> >> --=20 >> Thanks, >> >> David / dhildenb >=20 > If you don't mind, may i ask you exactly what security flaws you are ex= pecting > from uninitialized value allocation? I can think of below scenario: >=20 > 1. Security related value is freed by security system. > 2. Malicious module get allocation to the memory region that is freed b= y above. > 3. Malicious module uses that uninitialized value, and breach the secur= ity. >=20 I think one of the most important cases are "Content of process A is=20 leaked via driver/mechanism X to process B". Or "Kernel content is=20 leaked via driver/mechanism X to process Y". > Could you please confirm that I am think in the right way? If so, isn't= it > possible to make the security system to zero on free? I am not talking = about > CONFIG_INIT_ON_FREE_DEFAULT_ON. I am just suggesting that isn't it bett= er to > make programs that generate important values to be forced to initialize= on > free, instead of making whole system to zeroing on alloc always, result= ing > in performance downgrade? I think this approach can make enhancement. Well, it's not that easy. Then it's up to the freeing context to decide=20 if a page should better be freed. Similarly, if you have a BUG (e.g.,=20 random put_page() from context X frees a user space page to the buddy)=20 there, the whole security feature is - again - moot. That's why really=20 only "init_on_free" vs "init_on_alloc" make sense - for anything that=20 enters/leaves the buddy. As soon as you start poking holes you start=20 opening the door for such security issues. Enabling init_on_free has the downside that system boots gets slower, as=20 everything that enters the buddy (=3D=3D all memory) has to be zeroed out= . --=20 Thanks, David / dhildenb