lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 29 Mar 2021 19:12:55 +0900
From:   Hyunsoon Kim <h10.kim@...sung.com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, dseok.yi@...sung.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: add ___GFP_NOINIT flag which disables zeroing on
 alloc

On Mon, Mar 29, 2021 at 09:34:31AM +0300, Leon Romanovsky wrote:
> On Mon, Mar 29, 2021 at 02:29:10PM +0900, 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 Exynos
> > 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_alloc,
> > alloc_pages, etc.
> > 
> > Signed-off-by: Hyunsoon Kim <h10.kim@...sung.com>
> > ---
> >  include/linux/gfp.h | 2 ++
> >  include/linux/mm.h  | 4 +++-
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> Let's assume that we will use this new flag, and users are smart enough
> to figure when it needs to be used, what will be the performance gain?
> 
> Thanks

For instance, there are four memory access (either read or write) done
by the system; memory write due to page allocation for reserving memory
for modem hardware, memory write on the page by modem hardware,
read and write incurred by copy_to_user operation by iperf reading
the incoming network data. Theoretically, we can expect 1/4 of power
saving on DRAM bandwidth. By performing simple iperf test with download
UDP 800Mbps, we saw 5-6mA power gain by disabling
CONFIG_INIT_ON_ALLOC_DEFAULT.

Thanks


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ