x86 User-Mode Instruction Prevention and winehq

[Neri, Ricardo]

On Fri, 2016-11-18 at 14:16 -0600, Alexandre Julliard wrote:
> "Neri, Ricardo" <ricardo.neri at intel.com> writes:
> 
> > On Fri, 2016-11-18 at 10:56 -0600, Alexandre Julliard wrote:
> >> "Neri, Ricardo" <ricardo.neri at intel.com> writes:
> >> 
> >> > If running in protected mode, always propagate the GP fault to the user
> >> > space via a sigsegv. If running in vm86 mode, trap the GP fault within
> >> > the kernel and give the userspace fake values for the aforementioned
> >> > resources (most likely zeros).
> >> >
> >> > Also, UMIP will be able to be disabled via a kernel command-line
> >> > parameter at boot.
> >> >
> >> > I would like to inquire about the current use of these instructions and
> >> > whether it would be catastrophic for wine to lose access to them.
> >> 
> >> There are apps that use these instructions, so we'll need to catch and
> >> emulate them in the segfault handler. We have the infrastructure in
> >> place for that sort of thing so it shouldn't be hard. It does mean that
> >> these apps would get broken until users upgrade Wine though.
> >
> > Thanks for the feedback. The consensus in the kernel mailing list is to
> > catch the gp fault within the kernel and give the userspace fake values
> > for the GDT, LDT, IDT and the MSW (I don't think there are vm86 apps
> > that use the task register, are they?). This is because the goal of the
> > feature is to hide these tables from the user space. Would this be a
> > problem?
> 
> That sort of depends on what fake values you are returning. Currently we
> rely on SIDT returning a non-accessible address, in order to catch the
> resulting memory accesses and fake the IDT contents.

I see. Would a null address suffice? That would be non-accessible.
> 
> Note that the apps I'm talking about are not DOS apps running in vm86
> mode, but Windows binaries running in protected mode, so if the
> emulation is only for vm86 mode they would still get broken.

This is good to know. I will look into emulating these instructions for
protected mode as well.
> 
> There may also be issues with DOS apps in vm86 mode of course, but we
> normally forward these to DOSBox now, so it's no longer much of a
> concern for Wine.
> 
Uh I see. Maybe I can look into trapping the fault for both vm86 and
protected mode. I will also check with the DOSBox team.