[RFC PATCH 0/3] arm64: relocatable kernel proof of concept

[Mark Rutland]

> > Possibly related to running with/detecting an offset, we need a way to
> > communicate that kASLR is active through the compressed kernel to
> > uncompressed kernel. x86 is going to be using x86's setup_data, but we
> > may need to generalize this. (The reasoning here is that when kaslr is
> > disabled at runtime, we should turn off other kernel ASLR, like module
> > offset ASLR, without duplicating kernel command line parameter parsing
> > -- which is what x86 is currently doing now.) Just examining the
> > offset isn't sufficient because perhaps we got randomized to offset 0.
> > :)
> >
> 
> There is no decompressor on arm64, just the core kernel Image. So if
> an offset needs to be chosen before branching into the kernel proper,
> it needs to be the bootloader that chooses it.

Agreed.

Our equivalent to setup_data is the DT /chosen node, and I don't think
we want to try parsing that before we've turned on the MMU.

However, for the UEFI boot case we could have the stub do something more
intelligent and choose a random physical offset itself.

> > You mention the linear mappings in "performance", which I worry may be
> > at odds with kASLR? Can large mappings still be used even when we've
> > got smaller alignment goals? Since you mention the "upper half of the
> > virtual address range", I assume ARM is built using the -2GB
> > addressing as used by x86, is that right? So it sounds like it would
> > be similar entropy to x86.
> >
> 
> I haven't quantified the performance gain, but it is arguably more
> efficient to map RAM using 1 GB blocks than using 2 MB sections.
> On the other part of the question, I really need to do more research
> on what x86 implements in the first place before even trying to answer
> it.

That might not always be true, depending on the TLB implementation
(though it's better to assume that it is, as it shouldn't result in a
performance loss).

Also, if you use DEBUG_RODATA the kernel won't be mapped with 1GB
mappings after early boot anyway.

Mark.