On 05/09/2019 09:26, Peter Zijlstra wrote: > On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote: > >> I don't know if you've spotted, but the prefix is a ud2a instruction >> followed by 'xen' in ascii. >> >> The KVM version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2 > While the Xen one disassebles to valid instructions, that KVM one does > not: > > .text > xen: > ud2; .ascii "xen" > kvm: > ud2; .ascii "kvm" > > disassembles like: > > 0000000000000000 <xen>: > 0: 0f 0b ud2 > 2: 78 65 js 69 <kvm+0x64> > 4: 6e outsb %ds:(%rsi),(%dx) > 0000000000000005 <kvm>: > 5: 0f 0b ud2 > 7: 6b .byte 0x6b > 8: 76 6d jbe 77 <kvm+0x72> > > Which is a bit unfortunate I suppose. At least they don't appear to > consume further bytes.
It does when you give objdump one extra byte to look at. 0000000000000005 <kvm>: 5: 0f 0b ud2 7: 6b 76 6d 00 imul $0x0,0x6d(%rsi),%esi I did try to point out that this property should have been checked before settling on 'kvm' as the string. As for the Xen prefix, it's introduction pre-dates me substantially, and I don't know whether the disassembly was considered, or we just got lucky. IMO, the string 'Xen' would would have been sightly nicer 0000000000000005 <Xen>: 5: 0f 0b ud2 7: 58 pop %rax 8: 65 6e outsb %gs:(%rsi),(%dx) but we're 13 years too late to amend this. > I know it is water under the bridge at this point; but you could've used > UD1 with a displacement with some 'unlikely' values. That way it > would've decoded to a single instruction. > > Something like: > > ud1 0x6e6578(%rax),%rax > > which spells out "xen\0" in the displacement: > > 48 0f b9 80 78 65 6e 00 :) I seem to recall UD0 and UD1 being very late to the documentation party. ~Andrew
