[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu-xyUDFto+Te+WLAqVpvzQWGZRcRrL570_ymcQ_r9s-bw@mail.gmail.com>
Date: Tue, 5 Jan 2016 22:24:14 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Kees Cook <keescook@...omium.org>
Cc: "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>, Mark Rutland <mark.rutland@....com>,
Leif Lindholm <leif.lindholm@...aro.org>, LKML <linux-kernel@...r.kernel.org>,
Stuart Yoder <stuart.yoder@...escale.com>, Sharma Bhupesh <bhupesh.sharma@...escale.com>,
Arnd Bergmann <arnd@...db.de>, Marc Zyngier <marc.zyngier@....com>,
Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [PATCH v2 00/13] arm64: implement support for KASLR
On 5 January 2016 at 21:08, Kees Cook <keescook@...omium.org> wrote:
> On Wed, Dec 30, 2015 at 7:25 AM, Ard Biesheuvel
> <ard.biesheuvel@...aro.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)
>
Yes, that makes sense. For the UEFI stub version of the randomization,
that is trivially achievable, since we already parse the command line
in that context. For the bare bootloader case, that is a bit more
involved, since we'd need to parse the FDT before applying the
relocations, or apply the relocations twice.
> - 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)
>
I will look into all of these. kexec support has been in flight for a
while now, but I have no idea when it is expected to land.
>> 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?
Not automatically, no.
> 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.
>
Well, I conveniently punted the RNG problem to the firmware, so as far
as the quality of the randomness is concerned, it is easy to shift the
blame. For the other stuff (including the quality of the translation
between a random number and a KASRL offset), I highly appreciate your
input.
> Very cool!
>
Thanks!
--
Ard.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
