[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 14 Aug 2017 18:03:48 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>, Nicolas Pitre <nico@...aro.org>,
Russell King <linux@...linux.org.uk>, Kees Cook <keescook@...omium.org>,
Thomas Garnier <thgarnie@...gle.com>, Marc Zyngier <marc.zyngier@....com>,
Mark Rutland <mark.rutland@....com>, Tony Lindgren <tony@...mide.com>,
Matt Fleming <matt@...eblueprint.co.uk>, Dave Martin <dave.martin@....com>
Subject: Re: [PATCH 00/30] implement KASLR for ARM
On Mon, Aug 14, 2017 at 5:49 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 14 August 2017 at 16:30, Arnd Bergmann <arnd@...db.de> wrote:
>> Can you explain how the random seed is passed from the bootloader
>> to the kernel when we don't use EFI? Is this implemented at all? I see
>> that you add a seed to "/chosen/kaslr-seed" in the EFI stub when using
>> the EFI boot services, but I don't see where that value gets read again
>> when we relocate the kernel.
> To allow other bootloaders to do the same, the kaslr metadata is
> exposed via a zImage header, containing the values of PAGE_OFFSET, the
> base of the vmalloc area and the randomization granularity. A
> bootloader can read these values, and taking the size of DRAM and the
> placement of initrd and DTB into account, it can choose a value for
> kaslr offset and write it back into the zImage header.
>
> This is a bit involved, but it is really difficult to make these
> things backward compatible, i.e., passing something in a register is
> not possible if that register was not mandated to be zero initially.
>
> Similarly, the decompressor passed the kaslr offset to the startup
> code in the core kernel. It does so by passing it in r3 and jumping 4
> bytes past the entry point. This way, we are backward compatible with
> configurations where the decompressor is not used, because in that
> case, you always jump to the first instruction, which zeroes r3.
There are two ideas we discussed in the past (but never implemented
them obviously):
- instead of reading the "kaslr-seed" in the decompressor, it could
simply hash all of the DT blob to get the seed. This way the bootloader
can put the random see anywhere it likes, and as an added bonus,
we also get a little bit more random behavior on machines that have
no entropy source at all but that do have things like a serial number or
mac address in DT. Obviously those would be constant across boots
but different between machines. The OS can also store a random
seed during shutdown in a location that the bootloader uses to
initialize /chosen/kaslr-seed or another property that we use to seed
the kernel PRNG at boot time.
- If we have a random number at boot but no way to pass it through
the DT, I think we actually /can/ pass it through registers: the
register state is undefined, so in the worst case using the XOR of
all registers gives us the same number on each boot, but the
if the loader is modified to store a random 32-bit number in any
of the registers that don't pass other information, we can use that
to calculate the kaslr-base.
Arnd
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.
