On Wed, Feb 07, 2018 at 11:01:29AM -0800, Linus Torvalds wrote: > On Wed, Feb 7, 2018 at 10:38 AM, Randy Dunlap <rdun...@infradead.org> 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. > > Looking at the latest one I can find (325462-065US), it does specify > that it has a modrm byte: > > 0F FF /r UD0 1 r32, r/m32 > > so I think that our opcode maps are wrong, and it's a bit dangerous to > put random constants right after the UD0. > > Maybe we should make our use of UD0 have a third byte: add a harmless > modrm byte before the warning constants? > > But yes, at least my objdump just thinks it's a bad 2-byte sequence, > and doesn't look at any modrm bytes at all.
Look what my objdump does: $ objdump --version GNU objdump (GNU Binutils for Debian) 2.29.90.20180122 $ objdump -dr defconfig-build/kernel/sched/core.o | grep ud0 183a: 0f ff 65 48 ud0 0x48(%rbp),%esp 1881: 0f ff c3 ud0 %ebx,%eax 18b1: 0f ff 89 c0 48 0f a3 ud0 -0x5cf0b740(%rcx),%ecx 1940: 0f ff 89 c0 48 0f a3 ud0 -0x5cf0b740(%rcx),%ecx 19c2: 0f ff 89 c0 48 0f a3 ud0 -0x5cf0b740(%rcx),%ecx So yeah, we're screwed :-( Adding a harmless modr/m to our UD0 would grow the kernel image. ARGGH