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 for Android: free password hash cracker in your pocket

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

Date: Thu, 4 Jan 2024 17:21:19 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Elizabeth Figura <zfigura@...eweavers.com>, 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 Thu, Jan 04, 2024, H. Peter Anvin wrote:
> On January 3, 2024 10:35:28 PM PST, Elizabeth Figura <zfigura@...eweavers.com> wrote:
> >That still leaves the question of performance though. If having to exit the VM 
> >that often for performance reasons isn't feasible, then that's still going to 
> >force us to implement from scratch an inordinate amount of kernel/library code 
> >inside the VM just to avoid the transition. Or, more likely, conclude that a 
> >hypervisor just isn't going to work for us.
> >
> >I'm not at all familiar with the arch code, and I'm sure I'm not asking 
> >anything interesting, but is it really impossible to put CPU_ENTRY_AREA_RO_IDT 
> >somewhere that doesn't truncate to NULL, and to put the GDT at a fixed address 
> >as well?
> 
> Putting the GDT at a fixed address is pretty much a no-go for a variety of
> reasons. As I said, a prctl() to specify the desired return information *on
> UMIP-capable hardware* is certainly doable. However, it does not address
> things like fixed selectors that have come up.
> 
> 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. KVM might be able to assist there by providing a "short-circuit
> mode", allowing a system call vmexit to invoke the system call directly
> rather than having to bounce back to user space – twice.

Heh, I recommend not re-opening that can of worms[1], though some of the follow-up
work[2] from the gVisor folks might be useful/relevant?

[1] https://lore.kernel.org/all/20220722230241.1944655-1-avagin@google.com
[2] https://lore.kernel.org/all/20230308073201.3102738-1-avagin@google.com