From: Michal Hocko <mhocko@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/3] mm: Shuffle initial free memory
Date: Tue, 16 Oct 2018 13:12:30 +0200 [thread overview]
Message-ID: <20181016111230.GR18839@dhcp22.suse.cz> (raw)
In-Reply-To: <CAGXu5j+PStxYhiJaWM-mt4+WWbS_WAfvyHoyZYD5ndDLN2SY6w@mail.gmail.com>
On Mon 15-10-18 15:25:47, Kees Cook wrote:
> On Wed, Oct 10, 2018 at 6:36 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> > While SLAB_FREELIST_RANDOM reduces the predictability of some local slab
> > caches it leaves vast bulk of memory to be predictably in order
> > allocated. That ordering can be detected by a memory side-cache.
> >
> > The shuffling is done in terms of CONFIG_SHUFFLE_PAGE_ORDER sized free
> > pages where the default CONFIG_SHUFFLE_PAGE_ORDER is MAX_ORDER-1 i.e.
> > 10, 4MB this trades off randomization granularity for time spent
> > shuffling. MAX_ORDER-1 was chosen to be minimally invasive to the page
> > allocator while still showing memory-side cache behavior improvements,
> > and the expectation that the security implications of finer granularity
> > randomization is mitigated by CONFIG_SLAB_FREELIST_RANDOM.
>
> Perhaps it would help some of the detractors of this feature to make
> this a runtime choice? Some benchmarks show improvements, some show
> regressions. It could just be up to the admin to turn this on/off
> given their paranoia levels? (i.e. the shuffling could become a no-op
> with a given specific boot param?)
Sure, making this a opt-in is really necessary but it would be even
_better_ to actually evaluate how much security relevance it has as
well. If for nothing else then to allow an educated decision rather than
a fear driven one. And that pretty much involves evaluation on how hard
it is to bypass the randomness. If I am going to pay some overhead I
would like to know how much hardening I get in return, right? Something
completely missing in the current evaluation so far.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-10-16 11:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 1:36 [PATCH v4 0/3] Randomize free memory Dan Williams
2018-10-11 1:36 ` Dan Williams
2018-10-11 1:36 ` [PATCH v4 1/3] mm: Shuffle initial " Dan Williams
2018-10-11 1:36 ` Dan Williams
2018-10-15 22:25 ` Kees Cook
2018-10-15 22:32 ` Dan Williams
2018-10-16 11:12 ` Michal Hocko [this message]
2018-10-11 1:36 ` [PATCH v4 2/3] mm: Move buddy list manipulations into helpers Dan Williams
2018-10-11 1:36 ` [PATCH v4 3/3] mm: Maintain randomization of page free lists Dan Williams
2018-10-11 1:36 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181016111230.GR18839@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.