linux-kernel - Re: x86 SGDT emulation for Wine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 04 Jan 2024 20:03:05 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>,
        Elizabeth Figura <zfigura@...eweavers.com>,
        Sean Christopherson <seanjc@...gle.com>
CC: x86@...nel.org, Linux Kernel <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
        wine-devel@...ehq.org
Subject: Re: x86 SGDT emulation for Wine

On January 4, 2024 6:47:04 PM PST, Andrew Cooper <andrew.cooper3@...rix.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.