linux.git/arch/arm/kernel/asm-offsets.c, branch v4.18

Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables

2018-06-14T03:21:18+00:00

The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO
option that picked the strongest stack protector that the compiler
supported.

That was all a nice cleanup - it makes no sense to have the AUTO case
now that the Kconfig phase can just determine the compiler support
directly.

HOWEVER.

It also meant that doing "make oldconfig" would now _disable_ the strong
stackprotector if you had AUTO enabled, because in a legacy config file,
the sane stack protector configuration would look like

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  # CONFIG_CC_STACKPROTECTOR_NONE is not set
  # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
  # CONFIG_CC_STACKPROTECTOR_STRONG is not set
  CONFIG_CC_STACKPROTECTOR_AUTO=y

and when you ran this through "make oldconfig" with the Kbuild changes,
it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
used to be disabled (because it was really enabled by AUTO), and would
disable it in the new config, resulting in:

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
  CONFIG_CC_STACKPROTECTOR=y
  # CONFIG_CC_STACKPROTECTOR_STRONG is not set
  CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

That's dangerously subtle - people could suddenly find themselves with
the weaker stack protector setup without even realizing.

The solution here is to just rename not just the old RECULAR stack
protector option, but also the strong one.  This does that by just
removing the CC_ prefix entirely for the user choices, because it really
is not about the compiler support (the compiler support now instead
automatially impacts _visibility_ of the options to users).

This results in "make oldconfig" actually asking the user for their
choice, so that we don't have any silent subtle security model changes.
The end result would generally look like this:

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
  CONFIG_STACKPROTECTOR=y
  CONFIG_STACKPROTECTOR_STRONG=y
  CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

where the "CC_" versions really are about internal compiler
infrastructure, not the user selections.

Acked-by: Masahiro Yamada 
Signed-off-by: Linus Torvalds

ARM: 8757/1: NOMMU: Support PMSAv8 MPU

2018-05-19T10:53:46+00:00

ARMv8R/M architecture defines new memory protection scheme - PMSAv8
which is not compatible with PMSAv7.

Key differences to PMSAv7 are:
 - Region geometry is defined by base and limit addresses
 - Addresses need to be either 32 or 64 byte aligned
 - No region priority due to overlapping regions are not allowed
 - It is unified, i.e. no distinction between data/instruction regions
 - Memory attributes are controlled via MAIR

This patch implements support for PMSAv8 MPU defined by ARMv8R/M
architecture.

Signed-off-by: Vladimir Murzin 
Signed-off-by: Russell King

ARM: 8754/1: NOMMU: Move PMSAv7 MPU under it's own namespace

2018-05-19T10:53:46+00:00

We are going to support different MPU which programming model is not
compatible to PMSAv7, so move PMSAv7 MPU under it's own namespace.

Tested-by: Szemz? András 
Tested-by: Alexandre TORGUE 
Signed-off-by: Vladimir Murzin 
Signed-off-by: Russell King

ARM: 8708/1: NOMMU: Rework MPU to be mostly done in C

2017-10-23T15:58:59+00:00

Currently, there are several issues with how MPU is setup:

 1. We won't boot if MPU is missing
 2. We won't boot if use XIP
 3. Further extension of MPU setup requires asm skills

The 1st point can be relaxed, so we can continue with boot CPU even if
MPU is missed and fail boot for secondaries only. To address the 2nd
point we could create region covering CONFIG_XIP_PHYS_ADDR - _end and
that might work for the first stage of MPU enable, but due to MPU's
alignment requirement we could cover too much, IOW we need more
flexibility in how we're partitioning memory regions... and it'd be
hardly possible to archive because of the 3rd point.

This patch is trying to address 1st and 3rd issues and paves the path
for 2nd and further improvements.

The most visible change introduced with this patch is that we start
using mpu_rgn_info array (as it was supposed?), so change in MPU setup
done by boot CPU is recorded there and feed to secondaries. It
allows us to keep minimal region setup for boot CPU and do the rest in
C. Since we start programming MPU regions in C evaluation of MPU
constrains (number of regions supported and minimal region order) can
be done once, which in turn open possibility to free-up "probe"
region early.

Tested-by: Szemző András 
Tested-by: Alexandre TORGUE 
Tested-by: Benjamin Gaignard 
Signed-off-by: Vladimir Murzin 
Signed-off-by: Russell King

ARM: signal handling support for FDPIC_FUNCPTRS functions

2017-09-10T23:31:46+00:00

Signal handlers are not direct function pointers but pointers to function
descriptor in that case. Therefore we must retrieve the actual function
address and load the GOT value into r9 from the descriptor before branching
to the actual handler.

If a restorer is provided, we also have to load its address and GOT from
its descriptor. That descriptor address and the code to load it is pushed
onto the stack to be executed as soon as the signal handler returns.

However, to be compatible with NX stacks, the FDPIC bounce code is also
copied to the signal page along with the other code stubs. Therefore this
code must get at the descriptor address whether it executes from the stack
or the signal page. To do so we use the stack pointer which points at the
signal stack frame where the descriptor address was stored. Because the
rt signal frame is different from the simpler frame, two versions of the
bounce code are needed, and two variants (ARM and Thumb) as well. The
asm-offsets facility is used to determine the actual offset in the signal
frame for each version, meaning that struct sigframe and rt_sigframe had
to be moved to a separate file.

Signed-off-by: Nicolas Pitre 
Acked-by: Mickael GUENE 
Tested-by: Vincent Abriou 
Tested-by: Andras Szemzo

ARM: save and reset the address limit when entering an exception

2016-07-07T15:01:01+00:00

When we enter an exception, the current address limit should not apply
to the exception context: if the exception context wishes to access
kernel space via the user accessors (eg, perf code), it must explicitly
request such access.

Acked-by: Will Deacon 
Signed-off-by: Russell King

ARM: introduce svc_pt_regs structure

2016-06-22T18:54:52+00:00

Since the privileged mode pt_regs are an extended version of the saved
userland pt_regs, introduce a new svc_pt_regs structure to describe this
layout.

Acked-by: Will Deacon 
Signed-off-by: Russell King

ARM: rename S_FRAME_SIZE to PT_REGS_SIZE

2016-06-22T18:54:28+00:00

S_FRAME_SIZE is no longer the size of the kernel stack frame, so this
name is misleading.  It is the size of the kernel pt_regs structure.
Name it so.

Acked-by: Will Deacon 
Signed-off-by: Russell King

ARM: KVM: Remove unused hyp_pc field

2016-02-29T18:34:15+00:00

This field was never populated, and the panic code already
does something similar. Delete the related code.

Acked-by: Christoffer Dall 
Signed-off-by: Marc Zyngier

ARM: KVM: Cleanup asm-offsets.c

2016-02-29T18:34:15+00:00

Since we don't have much assembler left, most of the KVM stuff
in asm-offsets.c is now superfluous. Let's get rid of it.

Acked-by: Christoffer Dall 
Signed-off-by: Marc Zyngier