On Thu, Feb 08, 2018 at 09:31:46PM +0100, Borislav Petkov wrote:
> On Thu, Feb 08, 2018 at 08:44:06PM +0100, Peter Zijlstra wrote:
> > + * Since various instruction decoders/specs disagree on the encoding of
> > + * UD0/UD1,
>^
>
> Does that comma mean the sentence continues somewhere
On Thu, Feb 08, 2018 at 08:44:06PM +0100, Peter Zijlstra wrote:
> /*
> - * Since some emulators terminate on UD2, we cannot use it for WARN.
> - * Since various instruction decoders disagree on the length of UD1,
> - * we cannot use it either. So use UD0 for WARN.
> + * Despite that some emulators
On Thu, Feb 8, 2018 at 11:44 AM, Peter Zijlstra wrote:
>
> OK, here's the patch.. It leaves the UD0 in traps.c such that people
> could recompile their kernel with a simple change.
Ack, that seems about the best we can do.
Linus
On Thu, Feb 08, 2018 at 10:15:30AM -0800, Linus Torvalds wrote:
> On Thu, Feb 8, 2018 at 10:03 AM, Peter Zijlstra wrote:
> >
> > But yes, for our purposes UD2 is perfectly fine too, it will just mess
> > up the people doing bringup and the like.
>
> Oh, we'll inconvenience people inside Intel?
>
On Thu, Feb 8, 2018 at 10:03 AM, Peter Zijlstra wrote:
>
> But yes, for our purposes UD2 is perfectly fine too, it will just mess
> up the people doing bringup and the like.
Oh, we'll inconvenience people inside Intel?
The same people who changed and screwed up the definition of UD0 just
a coupl
On Thu, Feb 08, 2018 at 09:27:56AM -0800, Linus Torvalds wrote:
> On Thu, Feb 8, 2018 at 1:13 AM, Peter Zijlstra wrote:
> >
> > _The_ problem is that new binutils cannot sanely decode any function
> > that has a WARN in (this very much includes perf annotate):
>
> Ugh.
>
> Is there any reason wh
On Thu, Feb 8, 2018 at 1:13 AM, Peter Zijlstra wrote:
>
> _The_ problem is that new binutils cannot sanely decode any function
> that has a WARN in (this very much includes perf annotate):
Ugh.
Is there any reason why we don't just use UD2 and avoid this whole issue?
Do we even *do* anything di
On Thu, Feb 08, 2018 at 09:47:53AM +, David Laight wrote:
> From: Peter Zijlstra
> > 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 probab
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 it
On Thu, Feb 08, 2018 at 10:13:02AM +0100, Peter Zijlstra wrote:
> diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
> index 34d99af43994..f0d5b4a1512d 100644
> --- a/arch/x86/include/asm/bug.h
> +++ b/arch/x86/include/asm/bug.h
> @@ -12,16 +12,21 @@
> * (binutils knows about "u
On Thu, Feb 08, 2018 at 10:13:02AM +0100, Peter Zijlstra wrote:
> _The_ problem is that new binutils cannot sanely decode any function
> that has a WARN in (this very much includes perf annotate):
> new:
>
> 16a0 :
> 16a0: 48 89 f2mov%rsi,%rdx
> 16a3:
On Wed, Feb 07, 2018 at 11:43:37AM -0800, Linus Torvalds wrote:
> On Wed, Feb 7, 2018 at 11:28 AM, Borislav Petkov wrote:
> > On Wed, Feb 07, 2018 at 08:14:51PM +0100, Peter Zijlstra wrote:
> >> Then someone went and wrecked it.
> >
> > Yeah, note says UD0 didn't eat a ModRM byte on old CPUs. But
On Wed, Feb 07, 2018 at 11:43:37AM -0800, Linus Torvalds wrote:
> 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-cros
On Wed, Feb 7, 2018 at 11:28 AM, Borislav Petkov wrote:
> On Wed, Feb 07, 2018 at 08:14:51PM +0100, Peter Zijlstra wrote:
>> Then someone went and wrecked it.
>
> 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
On Wed, Feb 07, 2018 at 08:14:51PM +0100, Peter Zijlstra wrote:
> Then someone went and wrecked it.
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
On Wed, Feb 07, 2018 at 11:03:42AM -0800, Linus Torvalds wrote:
> On Wed, Feb 7, 2018 at 10:49 AM, Peter Zijlstra wrote:
> >
> > Right, we picked UD0 because we _thought_ everybody agreed it being 2
> > bytes, just like UD2. This is now not true anymore?
>
> Both UD0 and UD1 are documented to hav
On Wed, Feb 07, 2018 at 08:06:51PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 07, 2018 at 11:01:29AM -0800, Linus Torvalds wrote:
> > On Wed, Feb 7, 2018 at 10:38 AM, Randy Dunlap wrote:
> > > On 02/07/2018 10:13 AM, Linus Torvalds wrote:
> > >>
> > >> That said, intel only _documents_ UD2 (0f 0b)
On Wed, Feb 07, 2018 at 11:01:29AM -0800, Linus Torvalds wrote:
> On Wed, Feb 7, 2018 at 10:38 AM, Randy Dunlap wrote:
> > On 02/07/2018 10:13 AM, Linus Torvalds wrote:
> >>
> >> That said, intel only _documents_ UD2 (0f 0b).
> >
> > Intel Order Number: 325383-064US, October 2017, documents UD0, U
On Wed, Feb 7, 2018 at 10:49 AM, Peter Zijlstra wrote:
>
> Right, we picked UD0 because we _thought_ everybody agreed it being 2
> bytes, just like UD2. This is now not true anymore?
Both UD0 and UD1 are documented to have modrm in the latest Intel SDM
I can find (Order number 325462-065US, Decem
On Wed, Feb 7, 2018 at 10:38 AM, Randy Dunlap wrote:
> On 02/07/2018 10:13 AM, Linus Torvalds wrote:
>>
>> That said, intel only _documents_ UD2 (0f 0b).
>
> Intel Order Number: 325383-064US, October 2017, documents UD0, UD1, and UD2.
> Section A.2.5, Table A-1, says:
Ahh, I had an older version.
On Wed, Feb 07, 2018 at 07:35:43PM +0100, Borislav Petkov wrote:
> On Wed, Feb 07, 2018 at 10:13:35AM -0800, Linus Torvalds wrote:
> > Adding more people for this funky warning from the kbuild robot.
> >
> > Something is confused. UD0 is 0f ff, the bytes after that shouldn't
> > matter. But I gues
On 02/07/2018 10:13 AM, Linus Torvalds wrote:
> Adding more people for this funky warning from the kbuild robot.
>
> Something is confused. UD0 is 0f ff, the bytes after that shouldn't
> matter. But I guess they can be interpreted as modrm bytes, and
> somebody started doing that.
>
> That said,
On Wed, Feb 07, 2018 at 10:13:35AM -0800, Linus Torvalds wrote:
> Adding more people for this funky warning from the kbuild robot.
>
> Something is confused. UD0 is 0f ff, the bytes after that shouldn't
> matter. But I guess they can be interpreted as modrm bytes, and
> somebody started doing that
Adding more people for this funky warning from the kbuild robot.
Something is confused. UD0 is 0f ff, the bytes after that shouldn't
matter. But I guess they can be interpreted as modrm bytes, and
somebody started doing that.
That said, intel only _documents_ UD2 (0f 0b).
Maybe we should avoid u
24 matches
Mail list logo