[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <68d41324607f1169fcdfee95d95a25b4f4e772a3.camel@intel.com>
Date: Wed, 7 Nov 2018 20:03:49 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"daniel@...earbox.net" <daniel@...earbox.net>, "jeyu@...nel.org"
<jeyu@...nel.org>, "keescook@...omium.org" <keescook@...omium.org>,
"jannh@...gle.com" <jannh@...gle.com>, "willy@...radead.org"
<willy@...radead.org>, "tglx@...utronix.de" <tglx@...utronix.de>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "arjan@...ux.intel.com"
<arjan@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>,
"kristen@...ux.intel.com" <kristen@...ux.intel.com>, "hpa@...or.com"
<hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"Hansen, Dave" <dave.hansen@...el.com>
Subject: Re: [PATCH v8 2/4] x86/modules: Increase randomization for modules
On Tue, 2018-11-06 at 13:05 -0800, Andrew Morton wrote:
> On Fri, 2 Nov 2018 12:25:18 -0700 Rick Edgecombe <rick.p.edgecombe@...el.com>
> wrote:
>
> > This changes the behavior of the KASLR logic for allocating memory for the
> > text
> > sections of loadable modules. It randomizes the location of each module text
> > section with about 17 bits of entropy in typical use. This is enabled on
> > X86_64
> > only. For 32 bit, the behavior is unchanged.
> >
> > It refactors existing code around module randomization somewhat. There are
> > now
> > three different behaviors for x86 module_alloc depending on config.
> > RANDOMIZE_BASE=n, and RANDOMIZE_BASE=y ARCH=x86_64, and RANDOMIZE_BASE=y
> > ARCH=i386.
> >
> > The refactor of the existing code is to try to clearly show what
> > those behaviors are without having three separate versions or threading the
> > behaviors in a bunch of little spots. The reason it is not enabled on 32 bit
> > yet is because the module space is much smaller and simulations haven't been
> > run to see how it performs.
> >
> > The new algorithm breaks the module space in two, a random area and a backup
> > area. It first tries to allocate at a number of randomly located starting
> > pages
> > inside the random section without purging any lazy free vmap areas and
> > triggering the associated TLB flush.
> Surprised. Is one TLB flush per module loading sufficiently expensive
> to justify any effort to avoid it? IOW, please provide some
> justification and explanation in the changelog.
I'll fix this. The text is accurate, but misleading in communicating the
intentions because it was left over from an earlier version. Sorry about that.
I think the performance benefit might come more from avoiding the retry in
vmalloc, than the TLB flush. In the other mail I posted some benchmarks.
> > If this fails, then it will allocate in
> > the backup area. The backup area base will be offset in the same way as the
> > current algorithm does for the base area, 1024 possible locations.
>
> So presumably the allocation effort in the randomized section is
> somewhat likely to fail. That's unfortunate. Some discussion about
> why these failures occur would be helpful.
>
> Because it would be nice to do away with the backup area altogether.
> But this reader doesn't really understand why the backup area is
> needed.
With the high 10000 number tries, it usually only fails for larger modules until
the module space starts to get fuller. A concrete use case for the backup area
is when the random area is fragmented with BPF filters, and then the user tries
to load a large module.
For example imagine if you had the full 1GB of module space as the random area.
If you have 1000 BPF filters inserted, and they ended up being evenly
distributed, 1GB/1000=1MB, and so you couldn't load any modules over 1MB. With
2000, 0.5 MB, etc.
The 2/3:1/3 breakdown was chosen as my best guess at the best tradeoff of
fragmentation safety and entropy.
> > Due to boot_params being defined with different types in different places,
> > placing the config helpers modules.h or kaslr.h caused conflicts elsewhere,
> > and
> > so they are placed in a new file, kaslr_modules.h, instead.
> >
>
>
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.
