From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Slaby <jslaby@suse.cz>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
live-patching@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
the arch/x86 maintainers <x86@kernel.org>,
Andy Lutomirski <luto@kernel.org>, Jiri Kosina <jikos@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 7/7] DWARF: add the config option
Date: Fri, 26 May 2017 07:14:52 -0500 [thread overview]
Message-ID: <20170526121452.swfp365few62phph@treble> (raw)
In-Reply-To: <b877fd60-c9a4-cd2e-919a-68172f31285f@suse.cz>
On Fri, May 26, 2017 at 01:29:01PM +0200, Jiri Slaby wrote:
> On 05/26/2017, 08:54 AM, Jiri Slaby wrote:
> > On 05/19/2017, 11:35 PM, Josh Poimboeuf wrote:
> >> https://github.com/jpoimboe/linux/blob/undwarf/arch/x86/kernel/unwind_undwarf.c
> >
> > JFYI, it crashes in sha1_transform_avx due to crypto changes. You
> > perhaps missed that this beast uses ebp (not rbp) register for
> > computations. I had to do:
> >
> > --- a/arch/x86/crypto/sha1_ssse3_asm.S
> > +++ b/arch/x86/crypto/sha1_ssse3_asm.S
> > @@ -37,7 +37,7 @@
> > #define REG_A %ecx
> > #define REG_B %esi
> > #define REG_C %edi
> > -#define REG_D %ebp
> > +#define REG_D %r12d
> > #define REG_E %edx
> >
> > #define REG_T1 %eax
> > @@ -74,6 +74,7 @@
> > SYM_FUNC_START(\name)
> >
> > push %rbx
> > + push %r12
> > push %rbp
> >
> > mov %rsp, %rbp
> > @@ -99,6 +100,7 @@
> > rep stosq
> >
> > leaveq # deallocate workspace
> > + pop %r12
> > pop %rbx
> > ret
> >
> >
> > I am afraid there are more of these, e.g. in aesni-intel_asm.S.
>
> aesni-intel_asm.S is OK -- only untouched x86_32 part uses ebp.
>
> But sha1_avx2_x86_64_asm.S is not. They use *all* usable registers
> including ebp in the computations hidden behind the
> SHA1_PIPELINED_MAIN_BODY macro. The only work around I can see is to
> push rbp/pop rbp around the computation as it used to do with rbx:
>
> --- a/arch/x86/crypto/sha1_avx2_x86_64_asm.S
> +++ b/arch/x86/crypto/sha1_avx2_x86_64_asm.S
> @@ -636,6 +636,7 @@ _loop3:
> /* Align stack */
> mov %rsp, %rbp
> and $~(0x20-1), %rsp
> + push %rbp
> sub $RESERVE_STACK, %rsp
>
> avx2_zeroupper
> @@ -661,6 +662,7 @@ _loop3:
> avx2_zeroupper
>
> add $RESERVE_STACK, %rsp
> + pop %rbp
>
> leaveq
> pop %r15
Thanks, the first fix looks good. Is the second one needed though? It
already pushes rbp before it aligns the stack.
DWARF/undwarf will be immune to these issues, so I'll be moving a lot of
these crypto changes to a separate branch. They were only in this
branch because the new-and-improved objtool can now find rbp misusage in
leaf functions.
It seems that most of the crypto code is frame pointer ignorant. IMO,
leaf functions shouldn't be allowed to use rbp because it breaks frame
pointers when preempted by an interrupt. GCC seems to agree.
I added a check to objtool to find the ones which use rbp badly. Here
are the ones I see with my config:
arch/x86/crypto/des3_ede-asm_64.o: warning: objtool: des3_ede_x86_64_crypt_blk uses BP as a scratch register
arch/x86/crypto/des3_ede-asm_64.o: warning: objtool: des3_ede_x86_64_crypt_blk_3way uses BP as a scratch register
arch/x86/crypto/blowfish-x86_64-asm_64.o: warning: objtool: __blowfish_enc_blk_4way uses BP as a scratch register
arch/x86/crypto/blowfish-x86_64-asm_64.o: warning: objtool: blowfish_dec_blk_4way uses BP as a scratch register
arch/x86/crypto/twofish-x86_64-asm_64-3way.o: warning: objtool: __twofish_enc_blk_3way uses BP as a scratch register
arch/x86/crypto/twofish-x86_64-asm_64-3way.o: warning: objtool: twofish_dec_blk_3way uses BP as a scratch register
arch/x86/crypto/sha256-avx2-asm.o: warning: objtool: sha256_transform_rorx uses BP as a scratch register
arch/x86/crypto/cast5-avx-x86_64-asm_64.o: warning: objtool: __cast5_enc_blk16 uses BP as a scratch register
arch/x86/crypto/cast5-avx-x86_64-asm_64.o: warning: objtool: __cast5_dec_blk16 uses BP as a scratch register
arch/x86/crypto/cast6-avx-x86_64-asm_64.o: warning: objtool: __cast6_enc_blk8 uses BP as a scratch register
arch/x86/crypto/cast6-avx-x86_64-asm_64.o: warning: objtool: __cast6_dec_blk8 uses BP as a scratch register
arch/x86/crypto/twofish-avx-x86_64-asm_64.o: warning: objtool: __twofish_enc_blk8 uses BP as a scratch register
arch/x86/crypto/twofish-avx-x86_64-asm_64.o: warning: objtool: __twofish_dec_blk8 uses BP as a scratch register
(And that doesn't include the ones which misuse ebp.)
It may be a challenge to fix some of those which use all available
registers.
--
Josh
next prev parent reply other threads:[~2017-05-26 12:15 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 12:21 [PATCH 1/7] DWARF: add option to preserve unwind info Jiri Slaby
2017-05-05 12:21 ` [PATCH 2/7] DWARF: EH-frame based stack unwinding Jiri Slaby
2017-05-05 12:21 ` [PATCH 3/7] vmlinux.lds: preserve eh_frame for DWARF unwinder Jiri Slaby
2017-05-05 12:21 ` [PATCH 4/7] DWARF: initialize structures for kernel and modules Jiri Slaby
2017-05-05 12:21 ` [PATCH 5/7] unwinder: show_stack, check also ret_addr_p's contents Jiri Slaby
2017-05-05 12:21 ` [PATCH 6/7] unwinder: plug in the DWARF unwinder Jiri Slaby
2017-05-05 12:22 ` [PATCH 7/7] DWARF: add the config option Jiri Slaby
2017-05-05 19:57 ` Linus Torvalds
2017-05-06 7:19 ` Ingo Molnar
2017-05-10 7:46 ` Jiri Slaby
2017-05-06 14:24 ` Jiri Kosina
2017-05-07 16:55 ` Josh Poimboeuf
2017-05-07 17:59 ` Ingo Molnar
2017-05-07 18:08 ` hpa
2017-05-07 21:48 ` Josh Poimboeuf
2017-05-08 7:50 ` Vojtech Pavlik
2017-05-08 13:14 ` Josh Poimboeuf
2017-05-08 5:35 ` Andy Lutomirski
2017-05-08 6:15 ` Ingo Molnar
2017-05-08 14:40 ` Josh Poimboeuf
2017-05-08 18:57 ` hpa
2017-05-09 0:21 ` Andy Lutomirski
2017-05-09 1:38 ` Josh Poimboeuf
2017-05-09 2:31 ` Andy Lutomirski
2017-05-09 3:38 ` Josh Poimboeuf
2017-05-09 10:00 ` hpa
2017-05-09 14:58 ` Josh Poimboeuf
2017-05-09 16:46 ` H.J. Lu
2017-05-10 8:15 ` Jiri Slaby
2017-05-10 13:09 ` Josh Poimboeuf
2017-05-10 16:23 ` H.J. Lu
2017-05-09 18:47 ` Jiri Kosina
2017-05-09 19:22 ` Josh Poimboeuf
2017-05-10 8:32 ` Jiri Slaby
2017-05-10 13:13 ` Josh Poimboeuf
2017-05-23 7:07 ` Peter Zijlstra
2017-05-23 7:27 ` Ingo Molnar
2017-05-19 20:53 ` Josh Poimboeuf
2017-05-19 20:57 ` H. Peter Anvin
2017-05-19 20:59 ` H. Peter Anvin
2017-05-19 21:29 ` Josh Poimboeuf
2017-05-19 21:35 ` Josh Poimboeuf
2017-05-20 5:23 ` Andy Lutomirski
2017-05-20 16:20 ` Josh Poimboeuf
2017-05-20 17:19 ` Josh Poimboeuf
2017-05-20 20:01 ` H.J. Lu
2017-05-20 21:58 ` Andy Lutomirski
2017-05-20 22:20 ` H.J. Lu
2017-05-22 11:34 ` Jiri Kosina
2017-05-22 14:39 ` H.J. Lu
2017-05-22 21:07 ` H. Peter Anvin
2017-05-22 21:37 ` H. Peter Anvin
2017-05-22 22:11 ` Josh Poimboeuf
2017-05-20 20:16 ` Linus Torvalds
2017-05-20 21:56 ` Andy Lutomirski
2017-05-20 23:00 ` Linus Torvalds
2017-05-20 23:29 ` Linus Torvalds
2017-05-26 6:54 ` Jiri Slaby
2017-05-26 11:29 ` Jiri Slaby
2017-05-26 12:14 ` Josh Poimboeuf [this message]
2017-05-22 11:12 ` Ingo Molnar
2017-05-22 21:16 ` H. Peter Anvin
2017-05-22 23:23 ` Jiri Kosina
2017-05-23 5:49 ` Ingo Molnar
2017-05-26 19:16 ` hpa
2017-05-28 9:12 ` Ingo Molnar
2017-05-10 7:39 ` Jiri Slaby
2017-05-10 12:42 ` Josh Poimboeuf
2017-05-10 12:47 ` Jiri Slaby
2017-05-10 18:11 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170526121452.swfp365few62phph@treble \
--to=jpoimboe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jikos@kernel.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®