On Thu, Oct 01, 2015 at 08:10:26AM +0200, minipli@xxxxxxxxxxx wrote: > On Tue, Sep 22, 2015 at 10:47:04AM -0500, Josh Poimboeuf wrote: > > aesni-intel_asm.S has several callable non-leaf functions which don't > > honor CONFIG_FRAME_POINTER, which can result in bad stack traces. > > > > Create stack frames for them when CONFIG_FRAME_POINTER is enabled. > > > > Signed-off-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> > > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > > Cc: David S. Miller <davem@xxxxxxxxxxxxx> > > --- > > arch/x86/crypto/aesni-intel_asm.S | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S > > index 6bd2c6c..289ef12 100644 > > --- a/arch/x86/crypto/aesni-intel_asm.S > > +++ b/arch/x86/crypto/aesni-intel_asm.S > > @@ -31,6 +31,7 @@ > > > > #include <linux/linkage.h> > > #include <asm/inst.h> > > +#include <asm/frame.h> > > > > /* > > * The following macros are used to move an (un)aligned 16 byte value to/from > > @@ -1800,6 +1801,7 @@ ENDPROC(_key_expansion_256b) > > * unsigned int key_len) > > */ > > > ENTRY(aesni_set_key) > > + FRAME_BEGIN > > #ifndef __x86_64__ > > pushl KEYP > > movl 8(%esp), KEYP # ctx > > This will break 32 bit builds using the aesni-intel.ko module. You need > to adjust the esp-based offsets for the non-x86_64 case, as FRAME_BEGIN > may do another push. > > How about adding a FRAME_OFFSET() macro to <asm/frame.h> to wrap the > offsets?: > > #ifdef CONFIG_FRAME_POINTER > # define FRAME_OFFSET(x) ((x) + (BITS_PER_LONG / 8)) > #else > # define FRAME_OFFSET(x) (x) > #endif > > And using them like this: > > movl FRAME_OFFSET(8)(%esp), KEYP # ctx Ah, right. The 32-bit ABI passes arguments on the stack instead of via registers. For now, I'm inclined to just make FRAME_BEGIN and FRAME_END do nothing on 32-bit. We're only doing stack validation on x86_64 and I don't know if anybody cares about frame pointers on 32-bit at this point. -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
