From: Peter Zijlstra <peterz@infradead.org>
To: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
jpoimboe@redhat.com, jthierry@redhat.com, tglx@linutronix.de
Subject: Re: [PATCH V3 6/9] objtool: Report inconsistent stack changes in alternative
Date: Thu, 16 Apr 2020 16:18:43 +0200 [thread overview]
Message-ID: <20200416141843.GP20730@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200414103618.12657-7-alexandre.chartre@oracle.com>
On Tue, Apr 14, 2020 at 12:36:15PM +0200, Alexandre Chartre wrote:
> To allow a valid stack unwinding, an alternative should have code
> where the same stack changes happens at the same places as in the
> original code. Add a check in objtool to validate that stack changes
> in alternative are effectively consitent with the original code.
This thing is completely buggered, it warns all over the place, even for
obviously correct alternatives like:
0000000000000310 <return_to_handler>:
310: 48 83 ec 18 sub $0x18,%rsp
314: 48 89 04 24 mov %rax,(%rsp)
318: 48 89 54 24 08 mov %rdx,0x8(%rsp)
31d: 48 89 ef mov %rbp,%rdi
320: e8 00 00 00 00 callq 325 <return_to_handler+0x15>
321: R_X86_64_PLT32 ftrace_return_to_handler-0x4
325: 48 89 c7 mov %rax,%rdi
328: 48 8b 54 24 08 mov 0x8(%rsp),%rdx
32d: 48 8b 04 24 mov (%rsp),%rax
331: 48 83 c4 18 add $0x18,%rsp
335: ff e7 jmpq *%rdi
337: 90 nop
338: 90 nop
339: 90 nop
Where 335 has two alternatives:
0: e9 00 00 00 00 jmpq 5 <.altinstr_replacement+0x5>
1: R_X86_64_PLT32 __x86_retpoline_rdi-0x4
and
5: 0f ae e8 lfence
8: ff e7 jmpq *%rdi
And it then comes back with:
defconfig-build/arch/x86/kernel/ftrace_64.o: warning: objtool: .entry.text+0x335: error in alternative
defconfig-build/arch/x86/kernel/ftrace_64.o: warning: objtool: .altinstr_replacement+0x5: in alternative 2
defconfig-build/arch/x86/kernel/ftrace_64.o: warning: objtool: .altinstr_replacement+0x8: misaligned alternative state change
which is just utter crap, JMP has no (CFI) state change.
next prev parent reply other threads:[~2020-04-16 14:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 10:36 [PATCH V3 0/9] objtool changes to check retpoline code Alexandre Chartre
2020-04-14 10:36 ` [PATCH V3 1/9] objtool: is_fentry_call() crashes if call has no destination Alexandre Chartre
2020-05-01 18:22 ` [tip: objtool/core] " tip-bot2 for Alexandre Chartre
2020-04-14 10:36 ` [PATCH V3 2/9] objtool: Allow branches within the same alternative Alexandre Chartre
2020-04-14 10:36 ` [PATCH V3 3/9] objtool: Add support for intra-function calls Alexandre Chartre
2020-04-14 12:07 ` Julien Thierry
2020-04-16 12:12 ` Miroslav Benes
2020-05-01 18:22 ` [tip: objtool/core] " tip-bot2 for Alexandre Chartre
2020-04-14 10:36 ` [PATCH V3 4/9] objtool: Handle return instruction with intra-function call Alexandre Chartre
2020-04-14 13:44 ` Julien Thierry
2020-04-14 10:36 ` [PATCH V3 5/9] objtool: Add return address unwind hints Alexandre Chartre
2020-04-14 16:16 ` Peter Zijlstra
2020-04-14 16:40 ` Alexandre Chartre
2020-04-14 17:56 ` Peter Zijlstra
2020-04-14 18:31 ` Alexandre Chartre
2020-04-14 18:42 ` Peter Zijlstra
2020-04-14 19:27 ` Alexandre Chartre
2020-04-14 19:48 ` Peter Zijlstra
2020-04-14 10:36 ` [PATCH V3 6/9] objtool: Report inconsistent stack changes in alternative Alexandre Chartre
2020-04-14 15:35 ` Julien Thierry
2020-04-14 22:41 ` kbuild test robot
2020-04-14 22:41 ` kbuild test robot
2020-04-14 23:09 ` kbuild test robot
2020-04-14 23:09 ` kbuild test robot
2020-04-16 14:18 ` Peter Zijlstra [this message]
2020-04-16 14:43 ` Alexandre Chartre
2020-04-14 10:36 ` [PATCH V3 7/9] x86/speculation: Change __FILL_RETURN_BUFFER to work with objtool Alexandre Chartre
2020-04-14 10:36 ` [PATCH V3 8/9] x86/speculation: Add return address unwind hints to retpoline and RSB stuffing Alexandre Chartre
2020-04-14 10:36 ` [PATCH V3 9/9] x86/speculation: Annotate intra-function calls Alexandre Chartre
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=20200416141843.GP20730@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alexandre.chartre@oracle.com \
--cc=jpoimboe@redhat.com \
--cc=jthierry@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.