[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Apr 2019 10:31:48 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Alexander Potapenko <glider@...gle.com>, akpm@...ux-foundation.org,
cl@...ux.com, dvyukov@...gle.com, keescook@...omium.org,
labbott@...hat.com, linux-mm@...ck.org,
linux-security-module@...r.kernel.org,
kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 1/3] mm: security: introduce the init_allocations=1 boot
option
On Thu 18-04-19 09:35:32, Dave Hansen wrote:
> On 4/18/19 8:42 AM, Alexander Potapenko wrote:
> > This 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.
>
> Isn't it better to do this at free time rather than allocation time? If
> doing it at free, you can't even have information leaks for pages that
> are in the allocator.
I would tend to agree here. Free path is usually less performance sensitive
than the allocation. Those really hot paths tend to defer the work.
I am also worried that an opt-out gfp flag would tend to be used
incorrectly as the history has shown for others - e.g. __GFP_TEMPORARY.
So I would rather see this robust without a fine tuning unless there is
real use case that would suffer from this and we can think of a
background scrubbing or something similar.
--
Michal Hocko
SUSE Labs
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.
