Message ID | 20220822172953.3918414-1-ardb@kernel.org |
---|---|
State | New |
Headers | show |
Series | efi: libstub: Disable struct randomization | expand |
On Mon, Aug 22, 2022 at 07:29:53PM +0200, Ard Biesheuvel wrote: > The EFI stub is a wrapper around the core kernel that makes it look like > a EFI compatible PE/COFF application to the EFI firmware. EFI > applications run on top of the EFI runtime, which is heavily based on > so-called protocols, which are struct types consisting [mostly] of > function pointer members that are instantiated and recorded in a > protocol database. > > These structs look like the ideal randomization candidates to the > randstruct plugin (as they only carry function pointers), but of course, > these protocols are contracts between the firmware that exposes them, > and the EFI applications (including our stubbed kernel) that invoke > them. This means that struct randomization for EFI protocols is not a > great idea, and given that the stub shares very little data with the > core kernel that is represented as a randomizable struct, we're better > off just disabling it completely here. > > Reported-by: Daniel Marth <daniel.marth@inso.tuwien.ac.at> > Tested-by: Daniel Marth <daniel.marth@inso.tuwien.ac.at> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Kees Cook <keescook@chromium.org> -Kees
On Mon, 22 Aug 2022 at 21:58, Kees Cook <keescook@chromium.org> wrote: > > On Mon, Aug 22, 2022 at 07:29:53PM +0200, Ard Biesheuvel wrote: > > The EFI stub is a wrapper around the core kernel that makes it look like > > a EFI compatible PE/COFF application to the EFI firmware. EFI > > applications run on top of the EFI runtime, which is heavily based on > > so-called protocols, which are struct types consisting [mostly] of > > function pointer members that are instantiated and recorded in a > > protocol database. > > > > These structs look like the ideal randomization candidates to the > > randstruct plugin (as they only carry function pointers), but of course, > > these protocols are contracts between the firmware that exposes them, > > and the EFI applications (including our stubbed kernel) that invoke > > them. This means that struct randomization for EFI protocols is not a > > great idea, and given that the stub shares very little data with the > > core kernel that is represented as a randomizable struct, we're better > > off just disabling it completely here. > > > > Reported-by: Daniel Marth <daniel.marth@inso.tuwien.ac.at> > > Tested-by: Daniel Marth <daniel.marth@inso.tuwien.ac.at> > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > Acked-by: Kees Cook <keescook@chromium.org> > I've queued this up as a fix with a cc:stable Thanks all, Ard.
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile index d0537573501e..dd8c8a218245 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -42,6 +42,13 @@ KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_SCS), $(KBUILD_CFLAGS)) # disable LTO KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO), $(KBUILD_CFLAGS)) +# +# struct randomization only makes sense for Linux internal types, which the EFI +# stub code never touches, so let's turn off struct randomization for the stub +# altogether +# +KBUILD_CFLAGS := $(filter-out $(RANDSTRUCT_CFLAGS), $(KBUILD_CFLAGS)) + GCOV_PROFILE := n # Sanitizer runtimes are unavailable and cannot be linked here. KASAN_SANITIZE := n