Re: [PATCH] arm64: defconfig: update and enable CONFIG_RANDOMIZE_BASE

[Ard Biesheuvel]

On Thu, 20 Jun 2019 at 09:47, Will Deacon <will.deacon@xxxxxxx> wrote:
>
> Hi Nick,
>
> On Wed, Jun 19, 2019 at 05:32:42PM -0700, Nick Desaulniers wrote:
> > Generated via:
> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig
> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make menuconfig
> > <enable CONFIG_RANDOMIZE_BASE aka KASLR>
> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make savedefconfig
> > $ mv defconfig arch/arm64/configs/defconfig
>
> Hmm, I'm in two minds about whether we want this on by default. On the plus
> side, it gets us extra testing coverage, although the /vast/ majority of
> firmware implementations I run into either don't pass a seed or don't
> provide a working EFI_RNG. Perhaps that's just a chicken-and-egg problem
> which can be solved if we shout loud enough when we fail to randomize; we'll
> also eventually be in a better position when CPUs start implementing the
> v8.5 RNG instructions (but don't hold your breath unless you have an
> unusually high lung capacity).
>

For testing coverage purposes, exercising the relocation machinery etc
even on no-kaslr boots would be beneficial imo. (The kernel is
relocated once for non-kaslr boots and twice for kaslr boots on kaslr
capable kernels)

> On the flip side, I worry that it could make debugging more difficult, but I
> don't know whether that's a genuine concern or not. I'm assuming you've
> debugged your fair share of crashes from KASLR-enabled kernels; how bad is
> it? (I'm thinking of the case where somebody mails you part of a panic log
> and a .config).
>

When you are debugging using GDB, it can get a bit tedious, since you
have to pass the offset when you load the symbols. However, in that
case, you can just pass 'nokaslr' unless you are debugging something
that is affected by the randomization.

For reading backtraces etc, nothing really changes, since we get
symbol+nnn/mmm entries (and the full panic log prints the KASLR offset
as well, in case it matters)

> Irrespective of the above, I know Catalin was running into issues with his
> automated tests where the kernel would die silently during early boot with
> some seeds.  That's a bit rubbish if it's still the case -- Catalin?
>

Yes, it would be good if we could fix that. In fact, I would argue
that having this change in would have increased the likelihood that
someone else would have spotted it and fixed it :-)

In fact, given how many Android phones are running this code: Nick,
can you check if there are any KASLR related kernel fixes that haven't
been upstreamed?

> Finally, I know that (K)ASLR can be a bit controversial amongst security
> folks, with some seeing it as purely a smoke-and-mirrors game with no
> tangible benefits other than making us feel better about ourselves. Is it
> still the case that it can be trivially bypassed, or do you see it actually
> preventing some attacks in production?
>
> Sorry for the barrage of questions, but I think enabling this one by default
> is quite a significant thing to do and probably deserves a bit of scrutiny
> beforehand.
>

I think it is mostly controversial among non-security folks, who think
that every mitigation by itself should be bullet proof. Security folks
tend to think more about how each layer reduces the attack surface,
hopefully resulting in a secure system when all layers are enabled.

So KASLR is known to be broken unless you enable KPTI as well, so that
is something we could take into account. I.e., mitigations that don't
reduce the attack surface at all are just pointless complexity, which
should obviously be avoided.

Another thing to note is that the runtime cost of KASLR is ~zero, with
the exception of the module PLTs. However, the latter could do with
some additional coverage as well, so in summary, I think enabling this
is a good thing. Otherwise, we could disable full module randomization
so that the module PLT code doesn't get used in practice.

Acked-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>