Date: Tue, 16 Apr 2019 14:04:49 +0200 From: Alexander Potapenko <glider@...gle.com> To: Vlastimil Babka <vbabka@...e.cz> 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 Tue, Apr 16, 2019 at 10:33 AM Vlastimil Babka <vbabka@...e.cz> wrote: > > On 4/12/19 2:45 PM, Alexander Potapenko wrote: > > +config INIT_HEAP_ALL > > + bool "Initialize kernel heap allocations" > > Calling slab and page allocations together as "heap" is rather uncommon > in the kernel I think. But I don't have a better word right now. We can provide two separate flags for slab and page allocator to avoid this. I cannot think of a situation where this level of control is necessary though (apart from benchmarking). > > + default n > > + help > > + Enforce initialization of pages allocated from page allocator > > + and objects returned by kmalloc and friends. > > + Allocated memory is initialized with zeroes, preventing possible > > + information leaks and making the control-flow bugs that depend > > + on uninitialized values more deterministic. > > + > > config GCC_PLUGIN_STRUCTLEAK_VERBOSE > > bool "Report forcefully initialized variables" > > depends on GCC_PLUGIN_STRUCTLEAK > > > -- 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.