Re: [PATCH v2 00/13] arm64: implement support for KASLR

[Kees Cook <keescook@chromium.org>]

On Wed, Dec 30, 2015 at 7:25 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> This series implements KASLR for arm64, by building the kernel as a PIE
> executable that can relocate itself at runtime, and moving it to a random
> offset in the vmalloc area. This v2 also implements physical randomization,
> i.e., it allows the kernel to deal with being loaded at any physical offset
> (modulo the required alignment), and invokes the EFI_RNG_PROTOCOL from the
> UEFI stub to obtain random bits and perform the actual randomization of the
> physical load address.

This is great! Thanks for working through all these details.

> Changes since v1/RFC:
> - This series now implements fully independent virtual and physical address
>   randomization at load time. I have recycled some patches from this series:
>   http://thread.gmane.org/gmane.linux.ports.arm.kernel/455151, and updated the
>   final UEFI stub patch to randomize the physical address as well.

I'd love to get virt/phy separated on x86. There was a series, but it
still needs more work. Any one on the kernel-hardening list want to
take a stab at this?

> - Added a patch to deal with the way KVM on arm64 makes assumptions about the
>   relation between kernel symbols and the linear mapping (on which the HYP
>   mapping is based), as these assumptions cease to be valid once we move the
>   kernel Image out of the linear mapping.
> - Updated the module PLT patch so it works on BE kernels as well.
> - Moved the constant Image header values to head.S, and updated the linker
>   script to provide the kernel size using R_AARCH64_ABS32 relocation rather
>   than a R_AARCH64_ABS64 relocation, since those are always resolved at build
>   time. This allows me to get rid of the post-build perl script to swab header
>   values on BE kernels.
> - Minor style tweaks.
>
> Notes:
> - These patches apply on top of Mark Rutland's pagetable rework series:
>   http://thread.gmane.org/gmane.linux.ports.arm.kernel/462438
> - The arm64 Image is uncompressed by default, and the Elf64_Rela format uses
>   24 bytes per relocation entry. This results in considerable bloat (i.e., a
>   couple of MBs worth of relocation data in an .init section). However, no
>   build time postprocessing is required, we rely fully on the toolchain to
>   produce the image
> - We have to rely on the bootloader to supply some randomness in register x1
>   upon kernel entry. Since we have no decompressor, it is simply not feasible
>   to collect randomness in the head.S code path before mapping the kernel and
>   enabling the MMU.
> - The EFI_RNG_PROTOCOL that is invoked in patch #13 to supply randomness on
>   UEFI systems is not universally available. A QEMU/KVM firmware image that
>   implements a pseudo-random version is available here:
>   http://people.linaro.org/~ard.biesheuvel/QEMU_EFI.fd.aarch64-rng.bz2
>   (requires access to PMCCNTR_EL0 and support for AES instructions)
>   See below for instructions how to run the pseudo-random version on real
>   hardware.
> - Only mildly tested. Help appreciated.
>
> Code can be found here:
> git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-kaslr-v2
> https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v2
>
> Patch #1 updates the OF code to allow the minimum memblock physical address to
> be overridden by the arch.
>
> Patch #2 introduces KIMAGE_VADDR as the base of the kernel virtual region.
>
> Patch #3 memblock_reserve()'s the .bss, swapper_pg_dir and idmap_pg_dir
> individually.
>
> Patch #4 rewrites early_fixmap_init() so it does not rely on the linear mapping
> (i.e., the use of phys_to_virt() is avoided)
>
> Patch #5 updates KVM on arm64 so it can deal with kernel symbols whose addresses
> are not covered by the linear mapping.
>
> Patch #6 moves the kernel virtual mapping to the vmalloc area, along with the
> module region which is kept right below it, as before.
>
> Patch #7 adds support for PLTs in modules so that relative branches can be
> resolved via a PLT if the target is out of range.
>
> Patch #8 moves to the x86 version of the extable implementation so that it no
> longer contains absolute addresses that require fixing up at relocation time,
> but uses relative offsets instead.
>
> Patch #9 reverts some changes to the Image header population code so we no
> longer depend on the linker to populate the header fields. This is necessary
> since the R_AARCH64_ABS relocations that are emitted for these fields are not
> resolved at build time for PIE executables.
>
> Patch #10 updates the code in head.S that needs to execute before relocation to
> avoid the use of values that are subject to dynamic relocation. These values
> will not be populated in PIE executables.
>
> Patch #11 allows the kernel Image to be loaded anywhere in physical memory, by
> decoupling PHYS_OFFSET from the base of the kernel image.
>
> Patch #12 implements the core KASLR, by taking randomness supplied in register x1
> and using it to move the kernel inside the vmalloc area.
>
> Patch #13 adds an invocation of the EFI_RNG_PROTOCOL to supply randomness to the
> kernel proper.

I see a few other things that we'll probably want to add:

- kaslr/nokaslr command line (to either ignore boot loader hint or UEFI rng)

- randomization of module load address (see get_module_load_offset in
arch/x86/kernel/module.c)

- panic reporting of offset (see register_kernel_offset_dumper in
arch/x86/kernel/setup.c)

- vmcoreinfo reporting of offset (though I can't find vmcoreinfo on
arm64, so maybe not, as kexec appears unimplemented)

> Ard Biesheuvel (13):
>   of/fdt: make memblock minimum physical address arch configurable
>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>   arm64: use more granular reservations for static page table
>     allocations
>   arm64: decouple early fixmap init from linear mapping
>   arm64: kvm: deal with kernel symbols outside of linear mapping
>   arm64: move kernel image to base of vmalloc area
>   arm64: add support for module PLTs
>   arm64: use relative references in exception tables
>   arm64: avoid R_AARCH64_ABS64 relocations for Image header fields
>   arm64: avoid dynamic relocations in early boot code
>   arm64: allow kernel Image to be loaded anywhere in physical memory
>   arm64: add support for relocatable kernel
>   arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR randomness
>
>  Documentation/arm64/booting.txt           |  15 ++-
>  arch/arm/include/asm/kvm_asm.h            |   2 +
>  arch/arm/include/asm/kvm_mmu.h            |   2 +
>  arch/arm/kvm/arm.c                        |   9 +-
>  arch/arm/kvm/mmu.c                        |  12 +-
>  arch/arm64/Kconfig                        |  18 +++
>  arch/arm64/Makefile                       |  10 +-
>  arch/arm64/include/asm/assembler.h        |  17 ++-
>  arch/arm64/include/asm/boot.h             |   5 +
>  arch/arm64/include/asm/compiler.h         |   2 +
>  arch/arm64/include/asm/futex.h            |   4 +-
>  arch/arm64/include/asm/kasan.h            |  17 +--
>  arch/arm64/include/asm/kernel-pgtable.h   |   5 +-
>  arch/arm64/include/asm/kvm_asm.h          |  21 +--
>  arch/arm64/include/asm/kvm_mmu.h          |   2 +
>  arch/arm64/include/asm/memory.h           |  37 ++++--
>  arch/arm64/include/asm/module.h           |  11 ++
>  arch/arm64/include/asm/pgtable.h          |   7 -
>  arch/arm64/include/asm/uaccess.h          |  16 +--
>  arch/arm64/include/asm/virt.h             |   4 -
>  arch/arm64/kernel/Makefile                |   1 +
>  arch/arm64/kernel/armv8_deprecated.c      |   4 +-
>  arch/arm64/kernel/efi-entry.S             |   9 +-
>  arch/arm64/kernel/head.S                  | 133 ++++++++++++++++---
>  arch/arm64/kernel/image.h                 |  37 ++----
>  arch/arm64/kernel/module-plts.c           | 137 ++++++++++++++++++++
>  arch/arm64/kernel/module.c                |   7 +
>  arch/arm64/kernel/module.lds              |   4 +
>  arch/arm64/kernel/setup.c                 |  15 ++-
>  arch/arm64/kernel/vmlinux.lds.S           |  29 +++--
>  arch/arm64/kvm/debug.c                    |   4 +-
>  arch/arm64/mm/dump.c                      |  12 +-
>  arch/arm64/mm/extable.c                   | 102 ++++++++++++++-
>  arch/arm64/mm/init.c                      |  75 +++++++++--
>  arch/arm64/mm/mmu.c                       | 132 +++++++------------
>  drivers/firmware/efi/libstub/arm-stub.c   |   1 -
>  drivers/firmware/efi/libstub/arm64-stub.c | 134 ++++++++++++++++---
>  drivers/of/fdt.c                          |   5 +-
>  include/linux/efi.h                       |   5 +-
>  scripts/sortextable.c                     |   6 +-
>  virt/kvm/arm/vgic-v3.c                    |   2 +-
>  41 files changed, 813 insertions(+), 257 deletions(-)
>  create mode 100644 arch/arm64/kernel/module-plts.c
>  create mode 100644 arch/arm64/kernel/module.lds
>
>
> EFI_RNG_PROTOCOL on real hardware
> =================================
>
> To test whether your UEFI implements the EFI_RNG_PROTOCOL, download the
> following executable and run it from the UEFI Shell:
> http://people.linaro.org/~ard.biesheuvel/RngTest.efi
>
> FS0:\> rngtest
> UEFI RNG Protocol Testing :
> ----------------------------
>  -- Locate UEFI RNG Protocol : [Fail - Status = Not Found]
>
> If your UEFI does not implement the EFI_RNG_PROTOCOL, you can download and
> install the pseudo-random version that uses the generic timer and PMCCNTR_EL0
> values and permutes them using a couple of rounds of AES.
> http://people.linaro.org/~ard.biesheuvel/RngDxe.efi
>
> NOTE: not for production!! This is a quick and dirty hack to test the KASLR
> code, and is not suitable for anything else.
>
> FS0:\> rngdxe
> FS0:\> rngtest
> UEFI RNG Protocol Testing :
> ----------------------------
>  -- Locate UEFI RNG Protocol : [Pass]
>  -- Call RNG->GetInfo() interface :
>      >> Supported RNG Algorithm (Count = 2) :
>           0) 44F0DE6E-4D8C-4045-A8C7-4DD168856B9E
>           1) E43176D7-B6E8-4827-B784-7FFDC4B68561
>  -- Call RNG->GetRNG() interface :
>      >> RNG with default algorithm : [Pass]
>      >> RNG with SP800-90-HMAC-256 : [Fail - Status = Unsupported]
>      >> RNG with SP800-90-Hash-256 : [Fail - Status = Unsupported]
>      >> RNG with SP800-90-CTR-256 : [Pass]
>      >> RNG with X9.31-3DES : [Fail - Status = Unsupported]
>      >> RNG with X9.31-AES : [Fail - Status = Unsupported]
>      >> RNG with RAW Entropy : [Pass]
>  -- Random Number Generation Test with default RNG Algorithm (20 Rounds):
>           01) - 27
>           02) - 61E8
>           03) - 496FD8
>           04) - DDD793BF
>           05) - B6C37C8E23
>           06) - 4D183C604A96
>           07) - 9363311DB61298
>           08) - 5715A7294F4E436E
>           09) - F0D4D7BAA0DD52318E
>           10) - C88C6EBCF4C0474D87C3
>           11) - B5594602B482A643932172
>           12) - CA7573F704B2089B726B9CF1
>           13) - A93E9451CB533DCFBA87B97C33
>           14) - 45AA7B83DB6044F7BBAB031F0D24
>           15) - 3DD7A4D61F34ADCB400B5976730DCF
>           16) - 4DD168D21FAB8F59708330D6A9BEB021
>           17) - 4BBB225E61C465F174254159467E65939F
>           18) - 030A156C9616337A20070941E702827DA8E1
>           19) - AB0FC11C9A4E225011382A9D164D9D55CA2B64
>           20) - 72B9B4735DC445E5DA6AF88DE965B7E87CB9A23C
>

Have you done any repeated boot testing? When I originally did x86
kASLR, I had a machine rebooting over and over spitting the _text line
from /proc/kallsyms to the console. This both caught page table corner
cases where the system was unbootable and let me run a statistical
analysis of the offsets, just to make sure there wasn't any glaring
error in either the RNG or the relocation.

Very cool!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security