On Thu, 13 Aug, at 10:10:40PM, Josh Poimboeuf wrote: > efi_call() is a callable non-leaf function which doesn't honor > CONFIG_FRAME_POINTER, which can result in bad stack traces. > > Create a stack frame for it when CONFIG_FRAME_POINTER is enabled. > > Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com> > Cc: Matt Fleming <matt.flem...@intel.com> > --- > arch/x86/platform/efi/efi_stub_64.S | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/platform/efi/efi_stub_64.S > b/arch/x86/platform/efi/efi_stub_64.S > index 86d0f9e..0df2dcc 100644 > --- a/arch/x86/platform/efi/efi_stub_64.S > +++ b/arch/x86/platform/efi/efi_stub_64.S > @@ -11,6 +11,7 @@ > #include <asm/msr.h> > #include <asm/processor-flags.h> > #include <asm/page_types.h> > +#include <asm/frame.h> > > #define SAVE_XMM \ > mov %rsp, %rax; \ > @@ -74,6 +75,7 @@ > .endm > > ENTRY(efi_call) > + FRAME_BEGIN > SAVE_XMM > mov (%rsp), %rax > mov 8(%rax), %rax > @@ -88,6 +90,7 @@ ENTRY(efi_call) > RESTORE_PGT > addq $48, %rsp > RESTORE_XMM > + FRAME_END > ret > ENDPROC(efi_call)
You mention that stackvalidate will recursively validate the frame pointers in all code paths. Since we're calling into firmware code from efi_call(), we don't need to do anything special here right? I'm guessing stackvalidate would just stop since it has no way of knowing the target address of the %call instruction, but I just wanted to check (especially since the firmware ABI is different). Reviewed-by: Matt Fleming <matt.flem...@intel.com> -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
