[PATCH][RFC] arm64: kaslr: add pseudo-RNG in kernel

[Kees Cook]

On Fri, Feb 26, 2016 at 4:37 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> On 26 February 2016 at 13:18, Mark Rutland <mark.rutland at arm.com> wrote:
>> On Fri, Feb 26, 2016 at 12:51:25PM +0100, Ard Biesheuvel wrote:
>>> On 26 February 2016 at 12:01, Laurentiu Tudor <laurentiu.tudor at nxp.com> wrote:
>>> > In case the bootloader doesn't provide randomness
>>> > (through device tree or by uefi protocol) generate
>>> > a pseudo-random seed based on the timer counter.
>>> > People might find this "week rng" approach convenient
>>> > as it gets rid of the bootloader dependency.
>>> >
>>> > The patch tries to mimic the x86's rdtsc
>>> > based implementation authored by Kees Cook.
>>> >
>>> > Signed-off-by: Laurentiu Tudor <laurentiu.tudor at nxp.com>
>>> > Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>> > Cc: Kees Cook <keescook at chromium.org>
>>>
>>> Hi Laurentiu,
>>>
>>> I appreciate the interest in this work, but to be honest, I don't like
>>> this at all. I went out of my way to ensure that
>>> a) the kernel itself does not take part in generating the random bits, and
>>> b) the random bits are used in such a way that there is no correlation
>>> between the randomization of the core kernel, the module region and
>>> the linear region if there is no correlation between the random bits.
>>>
>>> The limited entropy of the cycle counter at early boot defeats that,
>>> and even worse, it will not encourage platform vendors to implement
>>> this properly in their boot code, given that it will appear to work,
>>> and the only thing more dangerous than no security is a false sense of
>>> security imo.
>>
>> I agree that a false sense of security is a worry here.
>>
>> Either way, I think we need numbers. It's non-obvious how much entropy
>> we can acquire through counters or other means at early boot time.
>>
>> Has anyone done an analysis of environmental entropy available (through
>> any means) at early boot, VM vs native?
>>
>
> Define 'environmental'. The only architected thing you can rely on is
> the timer, which really does not hold a lot of entropy on modern solid
> state platforms. I don't have the numbers, but I do have the
> experience to back this up, unfortunately (at my former employer).
>
> You could argue that KASLR does not require strong entropy like key
> generation, but I would prefer to simply steer clear of that entire
> debate. The bootloader simply needs to do the best job it can, either
> based on some peripheral that the kernel has no awareness of this
> early in the boot, or perhaps by other means if it doesn't (which
> could include storing a random seed in the file system, or even in a
> EFI variable). Punting it to the kernel is really the last resort.
>
>> It's also not obvious that vendors will correctly implement the EFI RNG
>> protocol; depending on the above we may want to mix in additional entropy
>> regardless.
>>
>
> True, but that is not the point. The main risk I see is that vendors
> will not bother at all once the digits start to look random to the
> human eye.

Surely there may be RNG sources that will come along in time that the
kernel can add to the entropy? I worry about boot loaders doing a
terrible job of finding a good RNG...

-Kees

>
>>> What I would ack, for development purposes, is something similar to
>>> what Mark Rutland implemented for randomizing TEXT_OFFSET, so that
>>> developers get to exercise this code even if their boot environment
>>> does not provide any entropy. Anything beyond that is a nack as far as
>>> I am concerned.
>>
>> FWIW, I would not like to see that approach. I can easily see a build-time
>> constant KASLR seed being abused to give a false sense of security. Having a
>> bootloader or hypervisor provide different random seeds to the same Image gives
>> you a much better turnaround time for testing regardless (vs rebuilding,
>> copying, etc).
>>
>
> If it would be *instead* of the ordinary handling, with a big fat
> blurb saying that KASLR is disabled, I would not mind.
>
>> The TEXT_OFFSET fuzzing was for fuzzing the bootloader, which is a bit
>> different to fuzzing the kernel itself.
>>
>> Mark.



-- 
Kees Cook
Chrome OS & Brillo Security