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

Mon Mar 16 16:19:25 PDT 2015

On Mon, Mar 16, 2015 at 8:23 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> These patches is a proof of concept of how we could potentially relocate
> the kernel at runtime. This code is rough around the edges, and there are
> a few unresolved issues, hence this RFC.
>
> With these patches, the kernel can essentially execute at any virtual offset.
> There are a couple of reasons why we would want this:
> - 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).
> - security: with these changes, we can put the kernel Image anywhere in physical
>   memory, and we can put the physical memory anywhere in the upper half of the
>   virtual address range (modulo alignment). This gives us quite a number of
>   bits of to play with if we were to randomize the kernel virtual address space.
>   Also, this is entirely under the control of the boot loader, which is probably
>   in better shape to get its hands on some entropy than the early kernel boot
>   code.

This is great! Thank you for working on this. ARM kernel text ASLR has
been on my TODO list for a while now, but I kept looking at the
missing relocation support and then would start crying. :) (Do you
have any plans for 32-bit ARM relocation support?)

Some random brain-dump from my experiences with kASLR on x86:

I don't want to exclusively depend on the bootloader for kASLR. There
is, I think, already a way to pass entropy into the kernel from the
bootloader, so perhaps that could be used on top of chipset-specific
entropy sources? I would like to try to keep the way kASLR gets
enabled/used/whatever at least compatible with x86 (which probably
means adding some additional knobs to x86 to gain what ARM will have).

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.
:)

For note, here's kernel module offset ASLR for ARM:
https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?h=kaslr/arm&id=773234f719a5cccb662840b90f41fad2930b2460

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.

We should keep in mind the idea of splitting physical ASLR from
virtual ASLR. The virtual addresses remain bound to the -2GB
addressing, but the kernel could be anywhere in physical RAM when
there is >4GB available. This is currently being worked on for x86.

> - convenience: fewer constraints when loading the kernel into memory, as it
>   can execute from anywhere.
>
> How it works:
> - an additional boot argument 'image offset' is passed in x1 by the boot loader,
>   which should contain a value that is at least the offset of Image into physical
>   memory. Higher values are also possible, and may be used to randomize the
>   kernel VA space.
> - the kernel binary is runtime relocated to PAGE_OFFSET + image offset
>
> 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.

I had no end of troubles with linkers changing their behavior. :) Have
you looked at arch/x86/tools/relocs* tool, or the reloc mechanisms in
arch/x86/boot/compressed/misc.c handle_relocations()? It looks like
you're using real ELF relocations in patch 2, which seems more
sensible that what x86 is doing (reinventing relocation tables). I'm
not sure why it's done that way, though.

> - 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.
> - Probably lots and lots of other roadblocks, hence this RFC
>
> Output from QEMU/efi with 2 GB of memory:
>
> Base of RAM:
>   0x000040000000-0x00004000ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>
> Physical location of Image:
>   0x00007f400000-0x00007fe6ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>
> Virtual kernel memory layout:
>     vmalloc : 0xffffff8000000000 - 0xffffffbdbfff0000   (   246 GB)
>     vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
>               0xffffffbdc1000000 - 0xffffffbdc3000000   (    32 MB actual)
>     fixed   : 0xffffffbffa9fe000 - 0xffffffbffac00000   (  2056 KB)
>     PCI I/O : 0xffffffbffae00000 - 0xffffffbffbe00000   (    16 MB)
>     modules : 0xffffffbffc000000 - 0xffffffc000000000   (    64 MB)
>     memory  : 0xffffffc000000000 - 0xffffffc080000000   (  2048 MB)
>       .init : 0xffffffc03fb82000 - 0xffffffc03fdbe000   (  2288 KB)
>       .text : 0xffffffc03f480000 - 0xffffffc03fb81344   (  7173 KB)
>       .data : 0xffffffc03fdc2000 - 0xffffffc03fe28c00   (   411 KB)
>
>
> Ard Biesheuvel (3):
>   arm64: head.S: replace early literals with constant immediates
>   arm64: add support for relocatable kernel
>   arm64/efi: use relocated kernel
>
>  arch/arm64/Kconfig              |  3 ++
>  arch/arm64/Makefile             |  4 ++
>  arch/arm64/kernel/efi-entry.S   |  6 ++-
>  arch/arm64/kernel/efi-stub.c    |  5 ++-
>  arch/arm64/kernel/head.S        | 94 +++++++++++++++++++++++++++++++----------
>  arch/arm64/kernel/image.h       |  8 +++-
>  arch/arm64/kernel/vmlinux.lds.S | 12 ++++++
>  scripts/sortextable.c           |  4 +-
>  8 files changed, 107 insertions(+), 29 deletions(-)
>
> --
> 1.8.3.2
>

I'll try to get this series into a state I can test on my hardware.
Thanks again!

-Kees

-- 
Kees Cook
Chrome OS Security