[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKyRK=h0sDFn6vqdKwmWds4EubqwnqVYG4JgKk=5-EDV7dJ36g@mail.gmail.com>
Date: Fri, 5 Apr 2013 15:06:02 -0700
From: Julien Tinnes <jln@...gle.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Kees Cook <keescook@...omium.org>, LKML <linux-kernel@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "x86@...nel.org" <x86@...nel.org>,
Jarkko Sakkinen <jarkko.sakkinen@...el.com>, Matthew Garrett <mjg@...hat.com>,
Matt Fleming <matt.fleming@...el.com>, Eric Northup <digitaleric@...gle.com>,
Dan Rosenberg <drosenberg@...curity.com>, Will Drewry <wad@...omium.org>
Subject: Re: [PATCH 3/3] x86: kernel base offset ASLR
On Fri, Apr 5, 2013 at 12:11 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Kees Cook <keescook@...omium.org> wrote:
>
>> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
>> can be randomized at boot.
>>
>> This makes kernel vulnerabilities harder to reliably exploit, especially
>> from remote attacks and local processes in seccomp containers. Keeping
>> the location of kernel addresses secret becomes very important when using
>> this feature, so enabling kptr_restrict and dmesg_restrict is recommended.
>> Besides direct address leaks, several other attacks are possible to bypass
>> this on local systems, including cache timing[1]. However, the benefits of
>> this feature in certain environments exceed the perceived weaknesses[2].
>>
>> An added security benefit is making the IDT read-only.
>>
>> Current entropy is low, since the kernel has basically a minimum 2MB
>> alignment and has been built with -2G memory addressing. As a result,
>> available entropy will be 8 bits in the best case. The e820 entries on
>> a given system may further limit the available memory.
>>
>> This feature is presently incompatible with hibernation.
>>
>> When built into the kernel, the "noaslr" kernel command line option will
>> disable the feature.
>>
>> Heavily based on work by Dan Rosenberg[3] and Neill Clift.
>>
>> [1] http://www.internetsociety.org/sites/default/files/Practical%20Timing%20Side%20Channel%20Attacks%20Against%20Kernel%20Space%20ASLR.pdf
>> [2] http://forums.grsecurity.net/viewtopic.php?f=7&t=3367
>> [3] http://lkml.indiana.edu/hypermail/linux/kernel/1105.3/index.html#00520
>>
>> Signed-off-by: Kees Cook <keescook@...omium.org>
>> Cc: Eric Northup <digitaleric@...gle.com>
>> ---
>> Documentation/kernel-parameters.txt | 4 +
>> arch/x86/Kconfig | 51 +++++++++++--
>> arch/x86/Makefile | 3 +
>> arch/x86/boot/compressed/head_32.S | 21 +++++-
>> arch/x86/boot/compressed/head_64.S | 135 ++++++++++++++++++++++++++++++++--
>> arch/x86/include/asm/fixmap.h | 4 +
>> arch/x86/include/asm/page_32_types.h | 2 +
>> arch/x86/include/asm/page_64_types.h | 4 -
>> arch/x86/include/asm/page_types.h | 4 +
>> arch/x86/kernel/asm-offsets.c | 14 ++++
>> arch/x86/kernel/setup.c | 24 ++++++
>> arch/x86/kernel/traps.c | 6 ++
>> 12 files changed, 251 insertions(+), 21 deletions(-)
>
> Before going into the details, I have a structural request: could you
> please further increase the granularity of the patch-set?
>
> In particular I'd suggest introducing a helper Kconfig bool that makes the
> IDT readonly - instead of using CONFIG_RANDOMIZE_BASE for that.
> CONFIG_RANDOMIZE_BASE can then select this helper Kconfig switch.
>
> Users could also select a readonly-IDT - even if they don't want a
> randomized kernel.
Speaking of IDT, and to capture some off-thread discussion here, we
should remember that the "SGDT" and "SIDT" instructions aren't
privileged on x86, so user-land can leak these out without any way for
the kernel to intercept that.
Adding their own random offsets to these two tables would be very
useful. This could be done in a later patchset of course.
Julien
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.
