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

[mark.rutland@arm.com (Mark Rutland)]

> >> - performance: we can align PHYS_OFFSET so that most of the linear mapping can
> >>   be done using 512 MB or 1 GB blocks (depending on page size), instead of
> >>   the more granular level that is currently unavoidable if Image cannot be
> >>   loaded at base of RAM (since PHYS_OFFSET is tied to the start of the kernel
> >>   Image).
> >
> > Isn't this gain somewhat offset by having to build the kernel as a PIE?
> 
> I don't think so. Note that this is not -fpic code, it's just the ld
> option that dumps the reloc and dynsym tables into the output image.
> The reloc penalty is boottime only.

Ah, ok.

> > I have a very strong suspicion that bootloaders in the wild don't zero
> > x1-x3, and that given that we might not have a reliable mechanism for
> > acquiring the offset.
> >
> 
> OK, sounds about time to start complaining about that then.

I guess so.

> >> Issues:
> >> - Since AArch64 uses the ELF RELA format (where the addends are in the
> >>   relocation table and not in the code), the relocations need to be applied even
> >>   if the Image runs from the same offset it was linked at. It also means that
> >>   some values that are produced by the linker (_kernel_size_le, etc) are missing
> >>   from the binary. This will probably need a fixup step.
> >> - The module area may be out of range, which needs to be worked around with
> >>   module PLTs. This is straight forward but I haven't implemented it yet for
> >>   arm64.
> >> - The core extable is most likely broken, and would need to be changed to use
> >>   relative offsets instead of absolute addresses.
> >
> > This sounds like it's going to be a big headache.
> >
> 
> It's all manageable, really. The module PLT thing is something I
> already implemented for 32-bit ARM here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305539.html
> (only Russell couldn't be bothered to merge it)
> 
> The extable is already relative on x86, and the fixup step is some
> straight forward ELF mangling on vmlinux before performing the
> objcopy.
> But yes, it's rather ugly.

Hmm. I'd be rather worried about the fixup step; I suspect that'll be
fragile and rarely tested. Perhaps we could verify them at boot time?

> > I'd rather see that we decouple the kernel (text/data) mapping from the
> > linear mapping, with the former given a fixed VA independent of the PA
> > of the kernel Image (which would still need to be at a 2M-aligned
> > address + text_offset, and not straddling a 512M boundary).
> >
> 
> Hmm, that's quite nice, actually, It also fixes the module range
> problem, and for VA randomization we could move both regions together.

Ah, good point. I hadn't consdiered modules all that much, but it sounds
like it could work.

Mark.