x86 User-Mode Instruction Prevention and winehq

[Alexandre Julliard]

"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.

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.

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.

-- 
Alexandre Julliard
julliard at winehq.org