On 03.04.23 21:06, Sean Christopherson wrote:
> On Mon, Apr 03, 2023, Mathias Krause wrote:
>> On 03.04.23 12:56, Mathias Krause wrote:
>>> Add support to enforce access tests to be handled by the emulator, if
>>> supported by KVM. Exclude it from the ac_test_exec() test, though, to
>>> not slow it down too much.
>>
>> I tend to read a lot of objdumps and when initially looking at the
>> generated code it was kinda hard to recognize the FEP instruction, as
>> the FEP actually decodes to UD2 followed by some IMUL instruction that
>> lacks a byte, so when objdump does its linear disassembly, it eats a
>> byte from the to-be-emulated instruction. Like, "FEP; int $0xc3" would
>> decode to:
>> 0: 0f 0b ud2
>> 2: 6b 76 6d cd imul $0xffffffcd,0x6d(%rsi),%esi
>> 6: c3 retq
>> This is slightly confusing, especially when the shortened instruction is
>> actually a valid one as above ("retq" vs "int $0xc3").
>>
>> I have the below diff to "fix" that. It adds 0x3e to the FEP which would
>> restore objdump's ability to generate a proper disassembly that won't
>> destroy the to-be-emulated instruction. As 0x3e decodes to the DS prefix
>> byte, which the emulator assumes by default anyways, this should mostly
>> be a no-op. However, it helped me to get a proper code dump.a
>
> I agree that the objdump output is annoying, but I don't love the idea of cramming
> in a prefix that's _mostly_ a nop.
>
> Given that FEP utilizes extremely specialized, off-by-default KVM code, what about
> reworking FEP in KVM itself to play nice with objdump (and other disasm tools)?
> E.g. "officially" change the magic prefix to include a trailing 0x3e. Though IMO,
> even better would be a magic value that decodes to a multi-byte nop, e.g.
> 0F 1F 44 00 00. The only "requirement" is that the magic value doesn't get
> false positives, and I can't imagine any of our test environments generate a ud2
> followed by a multi-byte nop.
Well, the above is a bad choice, actually, as that mirrors what GNU as
might generate when asked to generate a 5-byte NOP, e.g. for filling the
inter-function gap. And if there is a UD2 as last instruction and we're
unlucky to hit it, e.g. because we're hitting some UBSAN instrumented
error handling, we'll instead trigger "forced emulation" in KVM and
fall-through to the next function. Have fun debugging that! ;P
$ echo 'foo: ret; ud2; .balign 8; baz: int3' | as - && objdump -d
[...]
0000000000000000 <foo>:
0: c3 retq
1: 0f 0b ud2
3: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
0000000000000008 <baz>:
8: cc int3
>
> Keeping KVM-Unit-Tests and KVM synchronized on the correct FEP value would be a
> pain, but disconnects between KVM and KUT are nothing new.
Nah, that would be an ABI break, IMO a no-go. What I was suggesting was
pretty much the patch: change selective users in KUT to make them
objdump-friendly. The FEP as-is is ABI, IMO, and cannot be changed any
more. We could add a FEP2 that's more objdump-friedly, but there's
really no need to support yet another byte combination in KVM itself. It
can all be handled by its users, e.g. in KUT as proposed with the 0x3e
suffix.
But, as I said, it's mostly just me trying to read disassembly and I see
others don't have the need to. So this doesn't need to lead anywhere.
But I thought I bring it up, in case there's others questioning why some
of the KUT code dumps look so weird in objdump ;)
Thanks,
Mathias
