From: David Laight <David.Laight@ACULAB.COM>
To: "'Peter Zijlstra'" <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>,
kbuild test robot <fengguang.wu@intel.com>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>
Subject: RE: [linus:master] BUILD REGRESSION a2e5790d841658485d642196dbb0927303d6c22f
Date: Thu, 8 Feb 2018 09:47:53 +0000 [thread overview]
Message-ID: <c636fea6531b4c579f86e39c557b4c0d@AcuMS.aculab.com> (raw)
In-Reply-To: <20180208091302.GD25201@hirez.programming.kicks-ass.net>
From: Peter Zijlstra
> Sent: 08 February 2018 09:13
...
> > > Yeah, note says UD0 didn't eat a ModRM byte on old CPUs. But then that
> > > changed too. Fun stuff changing insn encoding underway.
> > >
> > > So if we opt for adding a ModRM byte, could a 0x90 NOP work so that it
> > > doesn't shit itself on those old CPUs?
> >
> > We could just also decide that the only thing that the modrm bytes of
> > UD0 actually *affect* is how the CPU might act for a page-crossing
> > instruction.
> >
> > Because I think that's the only semantic difference: if it's a
> > page-crosser, the instruction could take a page fault before raising
> > the #UD.
> >
> > Is there any other decode issue we might want to look out for?
>
> _The_ problem is that new binutils cannot sanely decode any function
> that has a WARN in (this very much includes perf annotate):
>
> old:
>
> 00000000000016a0 <copy_overflow>:
> 16a0: 48 89 f2 mov %rsi,%rdx
> 16a3: 89 fe mov %edi,%esi
> 16a5: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
> 16a8: R_X86_64_32S .rodata.str1.8+0x288
> 16ac: e8 00 00 00 00 callq 16b1 <copy_overflow+0x11>
> 16ad: R_X86_64_PC32 __warn_printk-0x4
> 16b1: 0f ff (bad)
> 16b3: c3 retq
> 16b4: 66 90 xchg %ax,%ax
> 16b6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
> 16bd: 00 00 00
>
> new:
>
> 00000000000016a0 <copy_overflow>:
> 16a0: 48 89 f2 mov %rsi,%rdx
> 16a3: 89 fe mov %edi,%esi
> 16a5: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
> 16a8: R_X86_64_32S .rodata.str1.8+0x288
> 16ac: e8 00 00 00 00 callq 16b1 <copy_overflow+0x11>
> 16ad: R_X86_64_PC32 __warn_printk-0x4
> 16b1: 0f ff c3 ud0 %ebx,%eax
> 16b4: 66 90 xchg %ax,%ax
> 16b6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
> 16bd: 00 00 00
>
>
> I went through the register opcodes and matched it against the ModR/M
> encoding, and the best option I've found so far is using 0xd6 as the
> next byte.
Wouldn't 0xc3 work as well.
A retq is probably better than an extra (bad).
Actually objdump ought to be more explicit than (bad) for the explicit UD0/1
David
next prev parent reply other threads:[~2018-02-08 9:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 11:44 [linus:master] BUILD REGRESSION a2e5790d841658485d642196dbb0927303d6c22f kbuild test robot
2018-02-07 18:13 ` Linus Torvalds
2018-02-07 18:35 ` Borislav Petkov
2018-02-07 18:49 ` Peter Zijlstra
2018-02-07 19:03 ` Linus Torvalds
2018-02-07 19:14 ` Peter Zijlstra
2018-02-07 19:28 ` Borislav Petkov
2018-02-07 19:43 ` Linus Torvalds
2018-02-07 20:24 ` Borislav Petkov
2018-02-08 9:13 ` Peter Zijlstra
2018-02-08 9:35 ` Peter Zijlstra
2018-02-08 9:46 ` Borislav Petkov
2018-02-08 9:47 ` David Laight [this message]
2018-02-08 10:13 ` Peter Zijlstra
2018-02-08 17:27 ` Linus Torvalds
2018-02-08 18:03 ` Peter Zijlstra
2018-02-08 18:15 ` Linus Torvalds
2018-02-08 19:44 ` Peter Zijlstra
2018-02-08 20:02 ` Linus Torvalds
2018-02-08 20:31 ` Borislav Petkov
2018-02-08 23:09 ` [PATCH 0/2] objtool fixes on top of Peter's WARN UD2 patch Josh Poimboeuf
2018-02-08 23:09 ` [PATCH 1/2] objtool: Fix seg fault in ignore_unreachable_insn() Josh Poimboeuf
2018-02-13 11:29 ` [tip:x86/pti] objtool: Fix segfault " tip-bot for Josh Poimboeuf
2018-02-15 0:26 ` tip-bot for Josh Poimboeuf
2018-02-08 23:09 ` [PATCH 2/2] x86: Annotate WARN-related UD2 as reachable Josh Poimboeuf
2018-02-13 11:30 ` [tip:x86/pti] x86/debug, objtool: Annotate WARN()-related " tip-bot for Josh Poimboeuf
2018-02-15 0:26 ` tip-bot for Josh Poimboeuf
2018-02-09 8:13 ` [PATCH 0/2] objtool fixes on top of Peter's WARN UD2 patch Peter Zijlstra
2018-02-09 8:12 ` [linus:master] BUILD REGRESSION a2e5790d841658485d642196dbb0927303d6c22f Peter Zijlstra
2018-02-13 11:30 ` [tip:x86/pti] x86/debug: Use UD2 for WARN() tip-bot for Peter Zijlstra
2018-02-15 0:27 ` tip-bot for Peter Zijlstra
2018-02-07 18:38 ` [linus:master] BUILD REGRESSION a2e5790d841658485d642196dbb0927303d6c22f Randy Dunlap
2018-02-07 19:01 ` Linus Torvalds
2018-02-07 19:06 ` Peter Zijlstra
2018-02-07 19:10 ` Peter Zijlstra
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=c636fea6531b4c579f86e39c557b4c0d@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=bp@alien8.de \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--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;
as well as URLs for NNTP newsgroup(s).