Message ID | 20200128184934.77625-1-samitolvanen@google.com (mailing list archive) |
---|---|
Headers | show |
Series | add support for Clang's Shadow Call Stack | expand |
Hi Sami, On 28/01/2020 18:49, Sami Tolvanen wrote: > This patch series adds support for Clang's Shadow Call Stack > (SCS) mitigation, which uses a separately allocated shadow stack > to protect against return address overwrites. More information > can be found here: > > https://clang.llvm.org/docs/ShadowCallStack.html > > SCS provides better protection against traditional buffer > overflows than CONFIG_STACKPROTECTOR_*, but it should be noted > that SCS security guarantees in the kernel differ from the ones > documented for user space. The kernel must store addresses of > shadow stacks used by inactive tasks and interrupt handlers in > memory, which means an attacker capable reading and writing > arbitrary memory may be able to locate them and hijack control > flow by modifying shadow stacks that are not currently in use. > > SCS is currently supported only on arm64, where the compiler > requires the x18 register to be reserved for holding the current > task's shadow stack pointer. I found I had to add: | KBUILD_CFLAGS := $(filter-out -ffixed-x18 $(CC_FLAGS_SCS), $(KBUILD_CFLAGS)) to drivers/firmware/efi/libstub/Makefile, to get this going. I don't think there is much point supporting SCS for the EFIstub, its already isolated from the rest of the kernel's C code by the __efistub symbol prefix machinery, and trying to use it would expose us to buggy firmware at a point we can't handle it! I can send a patch if its easier for you, Thanks, James
On Tue, Feb 11, 2020 at 5:57 AM James Morse <james.morse@arm.com> wrote: > I found I had to add: > | KBUILD_CFLAGS := $(filter-out -ffixed-x18 $(CC_FLAGS_SCS), $(KBUILD_CFLAGS)) > > to drivers/firmware/efi/libstub/Makefile, to get this going. Ah, good catch! > I don't think there is much point supporting SCS for the EFIstub, its already isolated > from the rest of the kernel's C code by the __efistub symbol prefix machinery, and trying > to use it would expose us to buggy firmware at a point we can't handle it! Yes, fully agreed. > I can send a patch if its easier for you, It's not a problem, I will include a patch for this in v8. Sami