MFC r350362:


MFC r350362:

Pull in r366369 from upstream llvm trunk (by Francis Visoiu Mistrih):

[CodeGen][NFC] Simplify checks for stack protector index checking

Use `hasStackProtectorIndex()` instead of `getStackProtectorIndex()
>= 0`.

Pull in r366371 from upstream llvm trunk (by Francis Visoiu Mistrih):

[PEI] Don't re-allocate a pre-allocated stack protector slot

The LocalStackSlotPass pre-allocates a stack protector and makes sure
that it comes before the local variables on the stack.

We need to make sure that later during PEI we don't re-allocate a new
stack protector slot. If that happens, the new stack protector slot
will end up being **after** the local variables that it should be

Therefore, we would have two slots assigned for two different stack
protectors, one at the top of the stack, and one at the bottom. Since
PEI will overwrite the assigned slot for the stack protector, the
load that is used to compare the value of the stack protector will
use the slot assigned by PEI, which is wrong.

For this, we need to check if the object is pre-allocated, and re-use
that pre-allocated slot.

Differential Revision: https://reviews.llvm.org/D64757

Pull in r367068 from upstream llvm trunk (by Francis Visoiu Mistrih):

[CodeGen] Don't resolve the stack protector frame accesses until PEI

Currently, stack protector loads and stores are resolved during
LocalStackSlotAllocation (if the pass needs to run). When this is the
case, the base register assigned to the frame access is going to be
one of the vregs created during LocalStackSlotAllocation. This means
that we are keeping a pointer to the stack protector slot, and we're
using this pointer to load and store to it.

In case register pressure goes up, we may end up spilling this
pointer to the stack, which can be a security concern.

Instead, leave it to PEI to resolve the frame accesses. In order to
do that, we make all stack protector accesses go through frame index
operands, then PEI will resolve this using an offset from sp/fp/bp.

Differential Revision: https://reviews.llvm.org/D64759

Together, these fix a issue where the stack protection feature in LLVM's
ARM backend can be rendered ineffective when the stack protector slot is
re-allocated so that it appears after the local variables that it is
meant to protect, leaving the function potentially vulnerable to a
stack-based buffer overflow.

Reported by: andrew
Security: https://kb.cert.org/vuls/id/129209/


dimJul 29 2019, 6:02 PM
rS350418: Add glue driver for Altera SOCFPGA Ethernet MAC (EMAC) found in