arm64: split linear and kernel mappings
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 8 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 8 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
Quoted 121 lines · Ard Biesheuvel
Quoted 116 lines · Matthias Brugger
Quoted 113 lines · Ard Biesheuvel
Quoted 110 lines · Matthias Brugger
Hi Ard,
Quoted 82 lines · Ard Biesheuvel
At the request of Catalin, this series has been split off from my series 'arm64: implement support for KASLR v4' [1]. This sub-series deals with moving the kernel out of the linear mapping into the vmalloc area. This is a prerequisite for independent physical and virtual randomization of the kernel image. On top of that, considering that these changes allow the linear mapping to start at an arbitrary offset above
PAGE_OFFSET, it should be an improvement in itself due to the fact that we can now choosePAGE_OFFSETsuch that RAM can be mapped using large block sizes.For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the lowest GB of RAM, which means
__pa(PAGE_OFFSET)is not 1 GB aligned, and the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly, for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using pages since__pa(PAGE_OFFSET)is not 512 MB aligned). With these changes
__pa(PAGE_OFFSET)will always be chosen such that it is aligned to a
quantity that allows efficient mapping.Note that of the entire KASLR series, this sub-series is the most likely to
cause problems, and hence requires the most careful review and testing. This
is due to the fact that, with these changes, the invariant __va(__pa(x)) == x
no longer holds, and any code that is based on that assumption needs to be
updated.Changes since v4:
- added Marc's ack to patch #6
- round the kasan zero shadow region around the kernel image to swapper blocksize (#7)- ensure that we don't clip the kernel image when clipping RAM to the linear
region size (#8)Patch #1 allows the low mark of memblocks discovered from the FDT to be overridden by the architecture.
Patch #2 enables the huge-vmap generic feature for arm64. This should be an
improvement in itself, but the significance for this series is that it allowsunmap_kernel_range()to be called on the [__init_begin,__init_end) region,
which may be partially mapped using block mappings.Patch #3 introduces
KIMAGE_VADDRas a separate, preparatory step towards decoupling the kernel placement fromPAGE_OFFSETPatch #4 implements some translation table accessors that operate on statically
allocate translation tables before the linear mapping is up.Patch #5 decouples the fixmap initialization from the linear mapping, by using
the accessors implemented by patch #4Patch #6 removes assumptions made my KVM regarding the placement of the kernel
image inside the linear mapping.Patch #7 moves the kernel image from the base of the linear mapping to the
base
of the vmalloc area. The modules area, which sits right below the kernel image,
is moved along and is put right before the start of the vmalloc area.Patch #8 decouples
PHYS_OFFSETfromPAGE_OFFSET, which allows the linear mapping
to cover all discovered memory, regardless of where the kernel image is located
in it. This effectively allows the kernel to be loaded at any physical address
(provided that the correct alignment is used)Quoted 11 lines
Ard Biesheuvel (8):
of/fdt: make memblock minimum physical address arch configurable
arm64: add support forioremap()block mappings
arm64: introduceKIMAGE_VADDRas the virtual base of the kernel
region
arm64: pgtable: implement static [pte|pmd|pud]_offset variants
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: allow kernel Image to be loaded anywhere in physical memoryI bisected linux-next (20160212) with the following error on booting with an
initramfs:
Failed to execute /init (error -8)
request_module: runaway loop modprobe binfmt-464c
Starting init:/sbin/initexists but couldn't execute it (error -8)
request_module: runaway loop modprobe binfmt-464c
Starting init:/bin/shexists but couldn't execute it (error -8)Kernel panic - not syncing: No working init found. Try passing init=option to kernel. See Linux
Documentation/init..Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
I tracked down the error to patch 7 of this series. But I realized that patch 7 does not compile, but from patch 8 onwards I observe the error.
Quoted 6 lines
As far as this failure is concerned, I managed to reproduce an error with patch #7 and not #8 applied, involving out of range kvm symbols at link time. This is reproducible with GCC 4.8 but not GCC 4.9 or later. Is this what you were seeing as well? Or is there another problem?
I realized that I used " aarch64-linux-gnu-gcc (Linaro GCC 2014.11) 4.9.3 20141031 (prerelease)" which gave me errors like:
arch/arm64/kvm/built-in.o: In function `__cpu_init_hyp_mode':
/home/mbrugger/src/linux-next/./arch/arm64/include/asm/kvm_host.h:331:(.text+0x73b4):
relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against symbol `__kvm_hyp_vector' defined in .hyp.text section in arch/arm64/kvm/built-in.o
So it was time to update my toolchain to "aarch64-linux-gnu-gcc (Linaro GCC 5.1-2015.08) 5.1.1 20150608" which fixed the problem for me.
Thanks,
Matthias
Quoted 49 lines
Quoted 49 lines
Quoted 11 lines
Quoted 6 lines
I use defconfig with an initramfs.cpio created with buildroot. I tested this on my mt8173 eval board, but I suppose this can be reproduced
easily on other machines as well.Thanks for the report. Does this help at all?
I applied them on top of linux-next and this fixed the problem.
Thanks,
MatthiasQuoted 30 lines
Quoted 30 lines
Regards,
MatthiasQuoted 25 lines
Documentation/arm64/booting.txt | 20 ++- Documentation/features/vm/huge-vmap/arch-support.txt | 2 +- arch/arm/include/asm/kvm_asm.h | 2 + arch/arm/kvm/arm.c | 8 +- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/boot.h | 6 + arch/arm64/include/asm/kasan.h | 2 +- arch/arm64/include/asm/kernel-pgtable.h | 12 ++ arch/arm64/include/asm/kvm_asm.h | 2 + arch/arm64/include/asm/kvm_host.h | 8 +- arch/arm64/include/asm/memory.h | 44 ++++-- arch/arm64/include/asm/pgtable.h | 23 ++- arch/arm64/kernel/head.S | 8 +- arch/arm64/kernel/image.h | 13 +- arch/arm64/kernel/vmlinux.lds.S | 4 +- arch/arm64/kvm/hyp.S | 6 +- arch/arm64/mm/dump.c | 12 +- arch/arm64/mm/init.c | 123 ++++++++++++++-- arch/arm64/mm/kasan_init.c | 31 +++- arch/arm64/mm/mmu.c | 155 +++++++++++++++----- drivers/of/fdt.c | 5 +- 21 files changed, 378 insertions(+), 109 deletions(-)