[PATCH v5sub1 0/8] arm64: split linear and kernel mappings

On 15 February 2016 at 14:29, Matthias Brugger [off-list ref] wrote:

On 13/02/16 15:28, Ard Biesheuvel wrote:

quoted

On 12 February 2016 at 21:10, Matthias Brugger [off-list ref]
wrote:

quoted

On 12/02/16 20:47, Ard Biesheuvel wrote:

quoted

On 12 February 2016 at 20:45, Matthias Brugger [off-list ref]
wrote:

quoted

Hi Ard,


On 01/02/16 11:54, Ard Biesheuvel wrote:

quoted

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
choose
PAGE_OFFSET such 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
block
     size (#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
allows
unmap_kernel_range() to be called on the [__init_begin, __init_end)
region,
which may be partially mapped using block mappings.

Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step
towards
decoupling the kernel placement from PAGE_OFFSET

Patch #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 #4

Patch #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_OFFSET from PAGE_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)

[1] http://thread.gmane.org/gmane.linux.kernel/2135931

Ard Biesheuvel (8):
     of/fdt: make memblock minimum physical address arch configurable
     arm64: add support for ioremap() block mappings
     arm64: introduce KIMAGE_VADDR as 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
memory

I 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/init exists but couldn't execute it (error -8)
   request_module: runaway loop modprobe binfmt-464c
   Starting init: /bin/sh exists 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..

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.

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.

OK, so it's the same issue, but I thought before that 4.9 worked ok,
which is indeed not the case (I checked)
This is a transient issue, since the subsequent patch replaces the
offending expressions, but to maintain bisectability, I will add a
workaround nonetheless.

Thanks,
Ard.