Re: x86 SGDT emulation for Wine

["H. Peter Anvin" <hpa@zytor.com>]

On January 4, 2024 6:47:04 PM PST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>On 05/01/2024 1:02 am, H. Peter Anvin wrote:
>> Note that there is no fundamental reason you cannot run the Unix user space code inside the VM container, too; you only need to vmexit on an actual system call.
>
>I know this is going on a tangent, but getting a VMExit on the SYSCALL
>instruction is surprisingly difficult.
>
>The "easy" way is to hide EFER.SCE behind the guests back, intercept #UD
>and emulate both the SYSCALL and SYSRET instructions.  It's slow, but it
>works.
>
>However, FRED completely prohibits tricks like this, because what you
>cannot reasonably do is clear CR4.FRED behind the back of a guest
>kernel.  You'd have to intercept and emulate all event sources in order
>to catch SYSCALL.
>
>I raised this as a concern during early review, but Intel has no
>official feature to take a VMExit on privilege change, and FRED
>(rightly) wasn't an appropriate vehicle to add such a feature, so it was
>deemed not an issue that the FRED design would break the unofficial ways
>that people were using to intercept/monitor/etc system calls.
>
>~Andrew
>
>P.S. Yes, there are more adventurous tricks like injecting a thunk into
>the guest kernel and editing MSR_LSTAR behind the guest's back.  In
>principle a similar trick works with FRED, but in order to do this to
>Windows, you also need to hook checkpatch to blind it to the thunk, and
>this is horribly invasive.

*In this case* it shouldn't be a problem, since the "guest operating system" would be virtually nonexistent and entirely puppeted by Wine.