linux-stable.git/arch/arm64/kernel/head.S, branch linux-3.19.y

arm64: head.S: ensure visibility of page tables

2015-05-06T20:01:56+00:00

commit 91d57155dc5ab4b311624b7ee570339b6af19ad5 upstream.

After writing the page tables, we use __inval_cache_range to invalidate
any stale cache entries. Strongly Ordered memory accesses are not
ordered w.r.t. cache maintenance instructions, and hence explicit memory
barriers are required to provide this ordering. However,
__inval_cache_range was written to be used on Normal Cacheable memory
once the MMU and caches are on, and does not have any barriers prior to
the DC instructions.

This patch adds a DMB between the page tables being written and the
corresponding cachelines being invalidated, ensuring that the
invalidation makes the new data visible to subsequent cacheable
accesses. A barrier is not required before the prior invalidate as we do
not access the page table memory area prior to this, and earlier
barriers in preserve_boot_args and set_cpu_boot_mode_flag ensures
ordering w.r.t. any stores performed prior to entering Linux.

Signed-off-by: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Fixes: c218bca74eeafa2f ("arm64: Relax the kernel cache requirements for boot")
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: Move some head.text functions to executable section

2014-11-26T17:19:47+00:00

The head.text section is intended to be run at early bootup
before any of the regular kernel mappings have been setup.
Parts of head.text may be freed back into the buddy allocator
due to TEXT_OFFSET so for security requirements this memory
must not be executable. The suspend/resume/hotplug code path
requires some of these head.S functions to run however which
means they need to be executable. Support these conflicting
requirements by moving the few head.text functions that need
to be executable to the text section which has the appropriate
page table permissions.

Tested-by: Kees Cook 
Reviewed-by: Mark Rutland 
Tested-by: Mark Rutland 
Signed-off-by: Laura Abbott 
Signed-off-by: Will Deacon

arm64: Switch to adrp for loading the stub vectors

2014-11-25T15:56:44+00:00

The hyp stub vectors are currently loaded using adr. This
instruction has a +/- 1MB range for the loading address. If
the alignment for sections is changed the address may be more
than 1MB away, resulting in reclocation errors. Switch to using
adrp for getting the address to ensure we aren't affected by the
location of the __hyp_stub_vectors.

Acked-by: Ard Biesheuvel 
Acked-by: Marc Zyngier 
Tested-by: Mark Rutland 
Tested-by: Kees Cook 
Signed-off-by: Laura Abbott 
Signed-off-by: Will Deacon

arm64/efi: set PE/COFF file alignment to 512 bytes

2014-11-05T08:03:09+00:00

Change our PE/COFF header to use the minimum file alignment of
512 bytes (0x200), as mandated by the PE/COFF spec v8.3

Also update the linker script so that the Image file itself is also a
round multiple of FileAlignment.

Acked-by: Catalin Marinas 
Acked-by: Roy Franz 
Signed-off-by: Ard Biesheuvel

arm64/efi: set PE/COFF section alignment to 4 KB

2014-11-05T08:03:05+00:00

Position independent AArch64 code needs to be linked and loaded at the
same relative offset from a 4 KB boundary, or adrp/add and adrp/ldr
pairs will not work correctly. (This is how PC relative symbol
references with a 4 GB reach are emitted)

We need to declare this in the PE/COFF header, otherwise the PE/COFF
loader may load the Image and invoke the stub at an offset which
violates this rule.

Reviewed-by: Roy Franz 
Acked-by: Mark Rutland 
Signed-off-by: Ard Biesheuvel

arm64/efi: efistub: jump to 'stext' directly, not through the header

2014-11-05T08:02:59+00:00

After the EFI stub has done its business, it jumps into the kernel by
branching to offset #0 of the loaded Image, which is where it expects
to find the header containing a 'branch to stext' instruction.

However, the UEFI spec 2.1.1 states the following regarding PE/COFF
image loading:
"A UEFI image is loaded into memory through the LoadImage() Boot
Service. This service loads an image with a PE32+ format into memory.
This PE32+ loader is required to load all sections of the PE32+ image
into memory."

In other words, it is /not/ required to load parts of the image that are
not covered by a PE/COFF section, so it may not have loaded the header
at the expected offset, as it is not covered by any PE/COFF section.

So instead, jump to 'stext' directly, which is at the base of the
PE/COFF .text section, by supplying a symbol 'stext_offset' to
efi-entry.o which contains the relative offset of stext into the Image.
Also replace other open coded calculations of the same value with a
reference to 'stext_offset'

Acked-by: Mark Rutland 
Acked-by: Roy Franz 
Signed-off-by: Ard Biesheuvel

arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text

2014-09-08T13:39:18+00:00

The static memory footprint of a kernel Image at boot is larger than the
Image file itself. Things like .bss data and initial page tables are allocated
statically but populated dynamically so their content is not contained in the
Image file.

However, if EFI (or GRUB) has loaded the Image at precisely the desired offset
of base of DRAM + TEXT_OFFSET, the Image will be booted in place, and we have
to make sure that the allocation done by the PE/COFF loader is large enough.

Fix this by growing the PE/COFF .text section to cover the entire static
memory footprint. The part of the section that is not covered by the payload
will be zero initialised by the PE/COFF loader.

Acked-by: Mark Salter 
Acked-by: Mark Rutland 
Acked-by: Leif Lindholm 
Tested-by: Leif Lindholm 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon

arm64: Remove unused variable in head.S

2014-08-26T18:24:00+00:00

Remove an unused local variable from head.S.  It seems this was never
used even from the initial commit
9703d9d7f77ce129621f7d80a844822e2daa7008 (arm64: Kernel booting and
initialisation), and is a left over from a previous implementation
of __calc_phys_offset.

Signed-off-by: Geoff Levand 
Signed-off-by: Will Deacon

arm64: align randomized TEXT_OFFSET on 4 kB boundary

2014-08-19T18:26:09+00:00

When booting via UEFI, the kernel Image is loaded at a 4 kB boundary and
the embedded EFI stub is executed in place. The EFI stub relocates the
Image to reside TEXT_OFFSET bytes above a 2 MB boundary, and jumps into
the kernel proper.

In AArch64, PC relative symbol references are emitted using adrp/add or
adrp/ldr pairs, where the offset into a 4 kB page is resolved using a
separate :lo12: relocation. This implicitly assumes that the code will
always be executed at the same relative offset with respect to a 4 kB
boundary, or the references will point to the wrong address.

This means we should link the kernel at a 4 kB aligned base address in
order to remain compatible with the base address the UEFI loader uses
when doing the initial load of Image. So update the code that generates
TEXT_OFFSET to choose a multiple of 4 kB.

At the same time, update the code so it chooses from the interval [0..2MB)
as the author originally intended.

Reviewed-by: Mark Rutland 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon

arm64: gicv3: Allow GICv3 compilation with older binutils

2014-07-25T12:12:15+00:00

GICv3 introduces new system registers accessible with the full msr/mrs
syntax (e.g. mrs x0, Sop0_op1_CRm_CRn_op2). However, only recent
binutils understand the new syntax. This patch introduces msr_s/mrs_s
assembly macros which generate the equivalent instructions above and
converts the existing GICv3 code (both drivers/irqchip/ and
arch/arm64/kernel/).

Signed-off-by: Catalin Marinas 
Reported-by: Olof Johansson 
Tested-by: Olof Johansson 
Suggested-by: Mark Rutland 
Acked-by: Mark Rutland 
Acked-by: Jason Cooper 
Cc: Will Deacon 
Cc: Marc Zyngier