Date: Fri, 12 Apr 2019 17:23:15 +0200 From: Alexander Potapenko <glider@...gle.com> To: Qian Cai <cai@....pw> Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-security-module <linux-security-module@...r.kernel.org>, Linux Memory Management List <linux-mm@...ck.org>, Nick Desaulniers <ndesaulniers@...gle.com>, Kostya Serebryany <kcc@...gle.com>, Dmitriy Vyukov <dvyukov@...gle.com>, Kees Cook <keescook@...omium.org>, Sandeep Patil <sspatil@...roid.com>, Laura Abbott <labbott@...hat.com>, Kernel Hardening <kernel-hardening@...ts.openwall.com> Subject: Re: [PATCH] mm: security: introduce CONFIG_INIT_HEAP_ALL On Fri, Apr 12, 2019 at 4:16 PM Qian Cai <cai@....pw> wrote: > > On Fri, 2019-04-12 at 14:45 +0200, Alexander Potapenko wrote: > > This config option adds the possibility to initialize newly allocated > > pages and heap objects with zeroes. This is needed to prevent possible > > information leaks and make the control-flow bugs that depend on > > uninitialized values more deterministic. > > > > Initialization is done at allocation time at the places where checks for > > __GFP_ZERO are performed. We don't initialize slab caches with > > constructors or SLAB_TYPESAFE_BY_RCU to preserve their semantics. > > > > For kernel testing purposes filling allocations with a nonzero pattern > > would be more suitable, but may require platform-specific code. To have > > a simple baseline we've decided to start with zero-initialization. > > > > No performance optimizations are done at the moment to reduce double > > initialization of memory regions. > > Sounds like this has already existed in some degree, i.e., > > CONFIG_PAGE_POISONING_ZERO Note that CONFIG_PAGE_POISONING[_ZERO] initializes freed pages, whereas the proposed patch initializes newly allocated pages. It's debatable whether initializing pages on kmalloc()/alloc_pages() is better or worse than doing so in kfree()/free_pages() from the security perspective. But the approach proposed in the patch makes it possible to use a special GFP flag to request uninitialized memory from the underlying allocator, so that we don't wipe it twice. This will be harder to do in the functions that free memory, because they don't accept GFP flags. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.