Re: [GIT PULL] x86/kaslr for v3.14

[Kees Cook <keescook@chromium.org>]

On Sun, Jan 26, 2014 at 10:49 PM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> On Mon, Jan 27, 2014 at 6:33 AM, H. Peter Anvin <hpa@linux.intel.com> wrote:
>> On 01/26/2014 02:16 AM, Richard Weinberger wrote:
>>>
>>> Currently we print the kernel offset only upon a panic() using the
>>> panic notifier list.
>>> This way it does not show up if the kernel hits a BUG() in process
>>> context or something less critical.
>>> Wouldn't make more sense to report the offset in every dump_stack() or
>>> show_regs() call?
>>
>> No, because that information is available to user space unless we panic.
>
> Didn't you mean non-root?
> I thought one has to set dmesg_restrict anyways if kASLR is used.
>
> And isn't the offset available to perf too?
> Of course only for root, but still user space.

Setting dmesg_restrict is done mostly in an effort to try to lock down
access to dmesg since it'll likely contain enough clues to help an
attacker. System owners need to avoid dmesg getting sprayed into
/var/log world-readable, or available via privileged debugging
daemons, etc. Since keeping dmesg secret from non-root users is going
to be error-prone, I had a goal of keeping the offset out of dmesg
while the system is still running -- hence doing it only at panic
time.

Finding the offset as the (unconfined) root user is extremely easy, so
I personally see no reason to hide it from root (and it would be very
irritating for things like perf, too). I view kASLR as a tool for
statistical defense against confined processes or remote attacks.

I would argue that decoding a non-panic oops on a running system is
entirely possible as-is, since the offset can be found from
/proc/kallsyms as root. It was the dead system that needed the offset
exported: via text in the panic, or via an ELF note in a core.

-Kees

-- 
Kees Cook
Chrome OS Security