The System V ABI for amd64 allows functions to use space in a 128 byte

redzone below the stack pointer for scratch space and requires
interrupt and signal frames to avoid overwriting it. However, EFI uses
the Windows ABI which does not support this. As a result, interrupt
handlers in EFI push their interrupt frames directly on top of the
stack pointer. If the compiler used the red zone in a function in the
EFI loader, then a device interrupt that occurred while that function
was running could trash its local variables.  In practice this happens
fairly reliable when using gzipfs as an interrupt during decompression
can trash the local variables in the inflate_table() function
resulting in corrupted output or hangs.

Fix this by disabling the redzone for amd64 EFI binaries. This
requires building not only the loader but any libraries used by the
loader without redzone support.

Thanks to Jilles for pointing me at the redzone once I found the stack
corruption.

Differential Revision:	https://reviews.freebsd.org/D2054
Reviewed by:	imp
MFC after:	2 weeks
Sponsored by:	Cisco Systems, Inc.

1 files changed, 1 insertions, 1 deletions

diff --git a/sys/boot/efi/libefi/Makefile b/sys/boot/efi/libefi/Makefile
index 3edeb22..bd753cf 100644
--- a/sys/boot/efi/libefi/Makefile
+++ b/sys/boot/efi/libefi/Makefile
@@ -9,7 +9,7 @@ SRCS=	delay.c efi_console.c efinet.c efipart.c errno.c handles.c \
 SRCS+= nullconsole.c comconsole.c
 
 .if ${MACHINE_ARCH} == "amd64"
-CFLAGS+= -fPIC
+CFLAGS+= -fPIC -mno-red-zone
 .endif
 CFLAGS+= -I${.CURDIR}/../include
 CFLAGS+= -I${.CURDIR}/../include/${MACHINE_CPUARCH}