Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Harald Arnesen]

Den 14/11/2016 11:59, skrev One Thousand Gnomes:


Is anyone actually still using DOSemu these days or are people all
using DOSbox ?

Alan


One thing lacking from DOSbox is TCP/IP networking.
--
Hilsen Harald

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Harald Arnesen]

Den 14/11/2016 11:59, skrev One Thousand Gnomes:


Is anyone actually still using DOSemu these days or are people all
using DOSbox ?

Alan


One thing lacking from DOSbox is TCP/IP networking.
--
Hilsen Harald

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[One Thousand Gnomes]

> I took a closer look at the dosemu code. It appears that it does not

That doesn't tell you want DOS itself will try and do...

> purposely utilize SGDT to obtain the descriptor table while in vm86. It
> does use SGDT (in protected mode) to emulate certain functionality such
> as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> However, this code seems to be disabled [1]. dosemu includes an i386
> emulator that in some cases uses the actual instructions of the host
> system. In such cases, UMIP might be needed to be disabled.

Is anyone actually still using DOSemu these days or are people all
using DOSbox ?

Alan

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[One Thousand Gnomes]

> I took a closer look at the dosemu code. It appears that it does not

That doesn't tell you want DOS itself will try and do...

> purposely utilize SGDT to obtain the descriptor table while in vm86. It
> does use SGDT (in protected mode) to emulate certain functionality such
> as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> However, this code seems to be disabled [1]. dosemu includes an i386
> emulator that in some cases uses the actual instructions of the host
> system. In such cases, UMIP might be needed to be disabled.

Is anyone actually still using DOSemu these days or are people all
using DOSbox ?

Alan

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Fri, 2016-11-11 at 23:51 +0300, Stas Sergeev wrote:
> 11.11.2016 07:14, Ricardo Neri пишет:
> >> 10.11.2016 09:46, Ricardo Neri пишет:
> >>> I took a closer look at the dosemu code. It appears that it does not
> >>> purposely utilize SGDT to obtain the descriptor table while in vm86. It
> >>> does use SGDT (in protected mode) to emulate certain functionality such
> >>> as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> >>> However, this code seems to be disabled [1].
> >> Indeed.
> >> The code you've found, was copied from wine, because
> >> dosemu supports windows-3.1. But sgdt is in win32s part
> >> that is disabled in dosemu. It is however enabled in wine, or
> >> at least it was when I ported the VxD code from there. So you
> >> may want to ask wine devs if they still use sgdt and vm86.
> >> In dosemu, if we ever enable win32s support, we won't rely
> >> on sgdt. In fact, when some prot mode program under dosemu
> >> uses GDT selectors, in a fault handler we replace them with
> >> LDT selectors.
> > Actually, the SLDT instruction is also impacted by this feature. This
> We do not support programs that do SLDT.
> The "polite" programs use special DPMI API extension to get
> the selector that covers LDT. That allows us to manage an "ldt
> alias" - memory buffer where we emulate LDT by write-protecting it.
> If we ever support SLDT, we would very much like to trap it
> and provide the pointer to our alias. Some very old dos extenders
> for 286 may start to work with such change, that are currently
> unsupported.

I see.
> 
> > feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
> > SMSW or STR are executed with CPL > 0. Would this be a problem for
> > dosemu?
> I am only a bit unsure about SMSW; the rest should be safe.
> Maybe some odd prog would use SMSW to check for FPU?
> Or to check for v86 mode by checking the PE bit?
> I am sure this is very uncommon, and if we find such prog, we
> can add an emulation of that instruction. I am pretty sure no one
> would get sufficiently hurt, but there will likely be 1-2 bug reports
> in our tracker, because if something is possible, then some DOS
> prog did that. :)

Fair enough.
> 
> >   The proposal now is to trap this GPU fault and give fake value
> > for these tables.
> If this fake value will be cooked up by the kernel without delivering
> the signal to dosemu process, then I don't see any problem at all.

Yes, the GP fault will be trapped in the kernel and not delivered to the
user space. All the user space will see is the fake value given by the
kernel.
> Of course you can provide the sane value for smsw.
> If that will go up to dosemu, then some coding may be needed
> on the user-space side.
> 
> > This is good news. This means that we could go ahead and give a fake
> > pointer to the GDT and the other impacted tables?
> Definitely.
> What these fake tables will look like, btw?
> Will they somehow resemble the real ones?
> Visible to user-space?
Since the intention is to hide these tables from the user space, I was
planning on giving 0x0 to all of it.

Thanks and BR,
Ricardo

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Fri, 2016-11-11 at 23:51 +0300, Stas Sergeev wrote:
> 11.11.2016 07:14, Ricardo Neri пишет:
> >> 10.11.2016 09:46, Ricardo Neri пишет:
> >>> I took a closer look at the dosemu code. It appears that it does not
> >>> purposely utilize SGDT to obtain the descriptor table while in vm86. It
> >>> does use SGDT (in protected mode) to emulate certain functionality such
> >>> as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> >>> However, this code seems to be disabled [1].
> >> Indeed.
> >> The code you've found, was copied from wine, because
> >> dosemu supports windows-3.1. But sgdt is in win32s part
> >> that is disabled in dosemu. It is however enabled in wine, or
> >> at least it was when I ported the VxD code from there. So you
> >> may want to ask wine devs if they still use sgdt and vm86.
> >> In dosemu, if we ever enable win32s support, we won't rely
> >> on sgdt. In fact, when some prot mode program under dosemu
> >> uses GDT selectors, in a fault handler we replace them with
> >> LDT selectors.
> > Actually, the SLDT instruction is also impacted by this feature. This
> We do not support programs that do SLDT.
> The "polite" programs use special DPMI API extension to get
> the selector that covers LDT. That allows us to manage an "ldt
> alias" - memory buffer where we emulate LDT by write-protecting it.
> If we ever support SLDT, we would very much like to trap it
> and provide the pointer to our alias. Some very old dos extenders
> for 286 may start to work with such change, that are currently
> unsupported.

I see.
> 
> > feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
> > SMSW or STR are executed with CPL > 0. Would this be a problem for
> > dosemu?
> I am only a bit unsure about SMSW; the rest should be safe.
> Maybe some odd prog would use SMSW to check for FPU?
> Or to check for v86 mode by checking the PE bit?
> I am sure this is very uncommon, and if we find such prog, we
> can add an emulation of that instruction. I am pretty sure no one
> would get sufficiently hurt, but there will likely be 1-2 bug reports
> in our tracker, because if something is possible, then some DOS
> prog did that. :)

Fair enough.
> 
> >   The proposal now is to trap this GPU fault and give fake value
> > for these tables.
> If this fake value will be cooked up by the kernel without delivering
> the signal to dosemu process, then I don't see any problem at all.

Yes, the GP fault will be trapped in the kernel and not delivered to the
user space. All the user space will see is the fake value given by the
kernel.
> Of course you can provide the sane value for smsw.
> If that will go up to dosemu, then some coding may be needed
> on the user-space side.
> 
> > This is good news. This means that we could go ahead and give a fake
> > pointer to the GDT and the other impacted tables?
> Definitely.
> What these fake tables will look like, btw?
> Will they somehow resemble the real ones?
> Visible to user-space?
Since the intention is to hide these tables from the user space, I was
planning on giving 0x0 to all of it.

Thanks and BR,
Ricardo

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Stas Sergeev]

11.11.2016 07:14, Ricardo Neri пишет:

10.11.2016 09:46, Ricardo Neri пишет:

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1].

Indeed.
The code you've found, was copied from wine, because
dosemu supports windows-3.1. But sgdt is in win32s part
that is disabled in dosemu. It is however enabled in wine, or
at least it was when I ported the VxD code from there. So you
may want to ask wine devs if they still use sgdt and vm86.
In dosemu, if we ever enable win32s support, we won't rely
on sgdt. In fact, when some prot mode program under dosemu
uses GDT selectors, in a fault handler we replace them with
LDT selectors.

Actually, the SLDT instruction is also impacted by this feature. This

We do not support programs that do SLDT.
The "polite" programs use special DPMI API extension to get
the selector that covers LDT. That allows us to manage an "ldt
alias" - memory buffer where we emulate LDT by write-protecting it.
If we ever support SLDT, we would very much like to trap it
and provide the pointer to our alias. Some very old dos extenders
for 286 may start to work with such change, that are currently
unsupported.


feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
SMSW or STR are executed with CPL > 0. Would this be a problem for
dosemu?

I am only a bit unsure about SMSW; the rest should be safe.
Maybe some odd prog would use SMSW to check for FPU?
Or to check for v86 mode by checking the PE bit?
I am sure this is very uncommon, and if we find such prog, we
can add an emulation of that instruction. I am pretty sure no one
would get sufficiently hurt, but there will likely be 1-2 bug reports
in our tracker, because if something is possible, then some DOS
prog did that. :)


  The proposal now is to trap this GPU fault and give fake value
for these tables.

If this fake value will be cooked up by the kernel without delivering
the signal to dosemu process, then I don't see any problem at all.
Of course you can provide the sane value for smsw.
If that will go up to dosemu, then some coding may be needed
on the user-space side.


This is good news. This means that we could go ahead and give a fake
pointer to the GDT and the other impacted tables?

Definitely.
What these fake tables will look like, btw?
Will they somehow resemble the real ones?
Visible to user-space?

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Stas Sergeev]

11.11.2016 07:14, Ricardo Neri пишет:

10.11.2016 09:46, Ricardo Neri пишет:

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1].

Indeed.
The code you've found, was copied from wine, because
dosemu supports windows-3.1. But sgdt is in win32s part
that is disabled in dosemu. It is however enabled in wine, or
at least it was when I ported the VxD code from there. So you
may want to ask wine devs if they still use sgdt and vm86.
In dosemu, if we ever enable win32s support, we won't rely
on sgdt. In fact, when some prot mode program under dosemu
uses GDT selectors, in a fault handler we replace them with
LDT selectors.

Actually, the SLDT instruction is also impacted by this feature. This

We do not support programs that do SLDT.
The "polite" programs use special DPMI API extension to get
the selector that covers LDT. That allows us to manage an "ldt
alias" - memory buffer where we emulate LDT by write-protecting it.
If we ever support SLDT, we would very much like to trap it
and provide the pointer to our alias. Some very old dos extenders
for 286 may start to work with such change, that are currently
unsupported.


feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
SMSW or STR are executed with CPL > 0. Would this be a problem for
dosemu?

I am only a bit unsure about SMSW; the rest should be safe.
Maybe some odd prog would use SMSW to check for FPU?
Or to check for v86 mode by checking the PE bit?
I am sure this is very uncommon, and if we find such prog, we
can add an emulation of that instruction. I am pretty sure no one
would get sufficiently hurt, but there will likely be 1-2 bug reports
in our tracker, because if something is possible, then some DOS
prog did that. :)


  The proposal now is to trap this GPU fault and give fake value
for these tables.

If this fake value will be cooked up by the kernel without delivering
the signal to dosemu process, then I don't see any problem at all.
Of course you can provide the sane value for smsw.
If that will go up to dosemu, then some coding may be needed
on the user-space side.


This is good news. This means that we could go ahead and give a fake
pointer to the GDT and the other impacted tables?

Definitely.
What these fake tables will look like, btw?
Will they somehow resemble the real ones?
Visible to user-space?

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Thu, 2016-11-10 at 11:52 +0300, Stas Sergeev wrote:
> Hi!
> 
> I don't know the context of that discussion, so I'll only
> comment on the dosemu part.

I'm sorry! I will cc you and the linux-msdos list in my v2.
> 
> 10.11.2016 09:46, Ricardo Neri пишет:
> > I took a closer look at the dosemu code. It appears that it does not
> > purposely utilize SGDT to obtain the descriptor table while in vm86. It
> > does use SGDT (in protected mode) to emulate certain functionality such
> > as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> > However, this code seems to be disabled [1].
> Indeed.
> The code you've found, was copied from wine, because
> dosemu supports windows-3.1. But sgdt is in win32s part
> that is disabled in dosemu. It is however enabled in wine, or
> at least it was when I ported the VxD code from there. So you
> may want to ask wine devs if they still use sgdt and vm86.
> In dosemu, if we ever enable win32s support, we won't rely
> on sgdt. In fact, when some prot mode program under dosemu
> uses GDT selectors, in a fault handler we replace them with
> LDT selectors.

Actually, the SLDT instruction is also impacted by this feature. This
feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
SMSW or STR are executed with CPL > 0. Would this be a problem for
dosemu? The proposal now is to trap this GPU fault and give fake value
for these tables.
> 
> >   dosemu includes an i386
> > emulator that in some cases uses the actual instructions of the host
> > system.
> In dosemu2 code, the places you've found, now contain this:
> error("SGDT not implemented\n");
> If we ever support SGDT, we'll use some emulation/fake values.
> 
> So overall, dosemu is not going to willingly use sgdt in any
> near future. But the programs running under vm86 or in prot mode
> may do so. This is very uncommon though, especially under dosemu,
> because it supports only a "polite" programs - those that work
> under win95's dos prompt. No one would get sufficiently hurt if
> sgdt under vm86 will somehow change from its current behaviour.

This is good news. This means that we could go ahead and give a fake
pointer to the GDT and the other impacted tables?
> 
> You can ask wine people for their sgdt use in win32s subsystem.

Will do.

Thanks and BR,
Ricardo

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Thu, 2016-11-10 at 11:52 +0300, Stas Sergeev wrote:
> Hi!
> 
> I don't know the context of that discussion, so I'll only
> comment on the dosemu part.

I'm sorry! I will cc you and the linux-msdos list in my v2.
> 
> 10.11.2016 09:46, Ricardo Neri пишет:
> > I took a closer look at the dosemu code. It appears that it does not
> > purposely utilize SGDT to obtain the descriptor table while in vm86. It
> > does use SGDT (in protected mode) to emulate certain functionality such
> > as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> > However, this code seems to be disabled [1].
> Indeed.
> The code you've found, was copied from wine, because
> dosemu supports windows-3.1. But sgdt is in win32s part
> that is disabled in dosemu. It is however enabled in wine, or
> at least it was when I ported the VxD code from there. So you
> may want to ask wine devs if they still use sgdt and vm86.
> In dosemu, if we ever enable win32s support, we won't rely
> on sgdt. In fact, when some prot mode program under dosemu
> uses GDT selectors, in a fault handler we replace them with
> LDT selectors.

Actually, the SLDT instruction is also impacted by this feature. This
feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
SMSW or STR are executed with CPL > 0. Would this be a problem for
dosemu? The proposal now is to trap this GPU fault and give fake value
for these tables.
> 
> >   dosemu includes an i386
> > emulator that in some cases uses the actual instructions of the host
> > system.
> In dosemu2 code, the places you've found, now contain this:
> error("SGDT not implemented\n");
> If we ever support SGDT, we'll use some emulation/fake values.
> 
> So overall, dosemu is not going to willingly use sgdt in any
> near future. But the programs running under vm86 or in prot mode
> may do so. This is very uncommon though, especially under dosemu,
> because it supports only a "polite" programs - those that work
> under win95's dos prompt. No one would get sufficiently hurt if
> sgdt under vm86 will somehow change from its current behaviour.

This is good news. This means that we could go ahead and give a fake
pointer to the GDT and the other impacted tables?
> 
> You can ask wine people for their sgdt use in win32s subsystem.

Will do.

Thanks and BR,
Ricardo

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Stas Sergeev]

Hi!

I don't know the context of that discussion, so I'll only
comment on the dosemu part.

10.11.2016 09:46, Ricardo Neri пишет:

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1].

Indeed.
The code you've found, was copied from wine, because
dosemu supports windows-3.1. But sgdt is in win32s part
that is disabled in dosemu. It is however enabled in wine, or
at least it was when I ported the VxD code from there. So you
may want to ask wine devs if they still use sgdt and vm86.
In dosemu, if we ever enable win32s support, we won't rely
on sgdt. In fact, when some prot mode program under dosemu
uses GDT selectors, in a fault handler we replace them with
LDT selectors.


  dosemu includes an i386
emulator that in some cases uses the actual instructions of the host
system.

In dosemu2 code, the places you've found, now contain this:
error("SGDT not implemented\n");
If we ever support SGDT, we'll use some emulation/fake values.

So overall, dosemu is not going to willingly use sgdt in any
near future. But the programs running under vm86 or in prot mode
may do so. This is very uncommon though, especially under dosemu,
because it supports only a "polite" programs - those that work
under win95's dos prompt. No one would get sufficiently hurt if
sgdt under vm86 will somehow change from its current behaviour.

You can ask wine people for their sgdt use in win32s subsystem.

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Stas Sergeev]

Hi!

I don't know the context of that discussion, so I'll only
comment on the dosemu part.

10.11.2016 09:46, Ricardo Neri пишет:

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1].

Indeed.
The code you've found, was copied from wine, because
dosemu supports windows-3.1. But sgdt is in win32s part
that is disabled in dosemu. It is however enabled in wine, or
at least it was when I ported the VxD code from there. So you
may want to ask wine devs if they still use sgdt and vm86.
In dosemu, if we ever enable win32s support, we won't rely
on sgdt. In fact, when some prot mode program under dosemu
uses GDT selectors, in a fault handler we replace them with
LDT selectors.


  dosemu includes an i386
emulator that in some cases uses the actual instructions of the host
system.

In dosemu2 code, the places you've found, now contain this:
error("SGDT not implemented\n");
If we ever support SGDT, we'll use some emulation/fake values.

So overall, dosemu is not going to willingly use sgdt in any
near future. But the programs running under vm86 or in prot mode
may do so. This is very uncommon though, especially under dosemu,
because it supports only a "polite" programs - those that work
under win95's dos prompt. No one would get sufficiently hurt if
sgdt under vm86 will somehow change from its current behaviour.

You can ask wine people for their sgdt use in win32s subsystem.

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Wed, 2016-11-09 at 03:05 -0800, Andy Lutomirski wrote:
> On Tue, Nov 8, 2016 at 8:31 PM, Ricardo Neri
>  wrote:
> > On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> >> > Would it not be better to emulate these instructions for them? What
> >> way
> >> > we can verify they're not malicious.
> >>
> >> Forget malice -- if they are really needed for some silly vm86-using
> >> program, let's trap them and emulate them so they return dummy values.
> >>
> >> Also, keep in mind that vm86 is already effectively gated behind a
> >> sysctl for non-root.  I think the default should be that, if root has
> >> enabled vm86, it should work.
> >
> > Then should I keep UMIP enabled by default and still provide an option
> > to disable it via a kernel parameter?
> 
> Probably, but clearcpuid might be good enough.  There might be some
> unexpected breakage.
> 
> >
> > Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
> > Under the new approach (of emulating the impacted instructions), this
> > option, a #GP fault would still be generated but the actual values of
> > GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?
> 
> I don't think so.  As far as I know, there is no legitimate reason for
> a vm86-using program to care about what these instructions spit out.
> Heck, in real mode and vm86 mode, there aren't segment descriptors at
> all, so the GDT is really quite useless even if it were readable.

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1]. dosemu includes an i386
emulator that in some cases uses the actual instructions of the host
system. In such cases, UMIP might be needed to be disabled.

So, yes, I agree now that UMIP does not need to be disabled specifically
for vm86 tasks but via clearcpuid.

Thanks and BR,
Ricardo
[1].
https://sourceforge.net/p/dosemu/code/ci/master/tree/src/dosext/dpmi/vxd.c#l731 
> 
> I would suggest having all of these instructions return compile-time
> constants in vm86 mode.

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Wed, 2016-11-09 at 03:05 -0800, Andy Lutomirski wrote:
> On Tue, Nov 8, 2016 at 8:31 PM, Ricardo Neri
>  wrote:
> > On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> >> > Would it not be better to emulate these instructions for them? What
> >> way
> >> > we can verify they're not malicious.
> >>
> >> Forget malice -- if they are really needed for some silly vm86-using
> >> program, let's trap them and emulate them so they return dummy values.
> >>
> >> Also, keep in mind that vm86 is already effectively gated behind a
> >> sysctl for non-root.  I think the default should be that, if root has
> >> enabled vm86, it should work.
> >
> > Then should I keep UMIP enabled by default and still provide an option
> > to disable it via a kernel parameter?
> 
> Probably, but clearcpuid might be good enough.  There might be some
> unexpected breakage.
> 
> >
> > Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
> > Under the new approach (of emulating the impacted instructions), this
> > option, a #GP fault would still be generated but the actual values of
> > GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?
> 
> I don't think so.  As far as I know, there is no legitimate reason for
> a vm86-using program to care about what these instructions spit out.
> Heck, in real mode and vm86 mode, there aren't segment descriptors at
> all, so the GDT is really quite useless even if it were readable.

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1]. dosemu includes an i386
emulator that in some cases uses the actual instructions of the host
system. In such cases, UMIP might be needed to be disabled.

So, yes, I agree now that UMIP does not need to be disabled specifically
for vm86 tasks but via clearcpuid.

Thanks and BR,
Ricardo
[1].
https://sourceforge.net/p/dosemu/code/ci/master/tree/src/dosext/dpmi/vxd.c#l731 
> 
> I would suggest having all of these instructions return compile-time
> constants in vm86 mode.

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Tue, Nov 8, 2016 at 8:31 PM, Ricardo Neri
 wrote:
> On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
>> > Would it not be better to emulate these instructions for them? What
>> way
>> > we can verify they're not malicious.
>>
>> Forget malice -- if they are really needed for some silly vm86-using
>> program, let's trap them and emulate them so they return dummy values.
>>
>> Also, keep in mind that vm86 is already effectively gated behind a
>> sysctl for non-root.  I think the default should be that, if root has
>> enabled vm86, it should work.
>
> Then should I keep UMIP enabled by default and still provide an option
> to disable it via a kernel parameter?

Probably, but clearcpuid might be good enough.  There might be some
unexpected breakage.

>
> Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
> Under the new approach (of emulating the impacted instructions), this
> option, a #GP fault would still be generated but the actual values of
> GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?

I don't think so.  As far as I know, there is no legitimate reason for
a vm86-using program to care about what these instructions spit out.
Heck, in real mode and vm86 mode, there aren't segment descriptors at
all, so the GDT is really quite useless even if it were readable.

I would suggest having all of these instructions return compile-time
constants in vm86 mode.

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Tue, Nov 8, 2016 at 8:31 PM, Ricardo Neri
 wrote:
> On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
>> > Would it not be better to emulate these instructions for them? What
>> way
>> > we can verify they're not malicious.
>>
>> Forget malice -- if they are really needed for some silly vm86-using
>> program, let's trap them and emulate them so they return dummy values.
>>
>> Also, keep in mind that vm86 is already effectively gated behind a
>> sysctl for non-root.  I think the default should be that, if root has
>> enabled vm86, it should work.
>
> Then should I keep UMIP enabled by default and still provide an option
> to disable it via a kernel parameter?

Probably, but clearcpuid might be good enough.  There might be some
unexpected breakage.

>
> Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
> Under the new approach (of emulating the impacted instructions), this
> option, a #GP fault would still be generated but the actual values of
> GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?

I don't think so.  As far as I know, there is no legitimate reason for
a vm86-using program to care about what these instructions spit out.
Heck, in real mode and vm86 mode, there aren't segment descriptors at
all, so the GDT is really quite useless even if it were readable.

I would suggest having all of these instructions return compile-time
constants in vm86 mode.

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> > Would it not be better to emulate these instructions for them? What
> way
> > we can verify they're not malicious.
> 
> Forget malice -- if they are really needed for some silly vm86-using
> program, let's trap them and emulate them so they return dummy values.
> 
> Also, keep in mind that vm86 is already effectively gated behind a
> sysctl for non-root.  I think the default should be that, if root has
> enabled vm86, it should work.

Then should I keep UMIP enabled by default and still provide an option
to disable it via a kernel parameter?

Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
Under the new approach (of emulating the impacted instructions), this
option, a #GP fault would still be generated but the actual values of
GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?

Thanks and BR,
Ricardo

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> > Would it not be better to emulate these instructions for them? What
> way
> > we can verify they're not malicious.
> 
> Forget malice -- if they are really needed for some silly vm86-using
> program, let's trap them and emulate them so they return dummy values.
> 
> Also, keep in mind that vm86 is already effectively gated behind a
> sysctl for non-root.  I think the default should be that, if root has
> enabled vm86, it should work.

Then should I keep UMIP enabled by default and still provide an option
to disable it via a kernel parameter?

Also, a third option, umip=novm86 would "disable" UMIP in vm86 tasks.
Under the new approach (of emulating the impacted instructions), this
option, a #GP fault would still be generated but the actual values of
GDT/LDT/IDT/MSW would be passed to user space. Does this make sense?

Thanks and BR,
Ricardo

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2016-11-08 at 17:52 +0100, Thomas Gleixner wrote:
> On Tue, 8 Nov 2016, Andy Lutomirski wrote:
> > On Tue, Nov 8, 2016 at 5:16 AM, Peter Zijlstra  wrote:
> > > On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote:
> > >> There is a caveat, however. Certain applications running in virtual-8086
> > >> mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and
> > >> SLDT instructions for legitimate reasons. In order to keep such
> > >> applications working, UMIP must be disabled/enabled when entering/exiting
> > >> virtual-8086 mode.
> > >
> > > Would it not be better to emulate these instructions for them? What way
> > > we can verify they're not malicious.
> > 
> > Forget malice -- if they are really needed for some silly vm86-using
> > program, let's trap them and emulate them so they return dummy values.
> 
> handle_vm86_fault() already does instruction emulation, so adding the few
> bits there is the right thing to do. Then we just can enable UMIP
> unconditionally and be done with it.

Ah. I didn't think about that. It make sense to me. I will rework this
series with this approach.
> 
> Thanks,
> 
>   tglx

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2016-11-08 at 17:52 +0100, Thomas Gleixner wrote:
> On Tue, 8 Nov 2016, Andy Lutomirski wrote:
> > On Tue, Nov 8, 2016 at 5:16 AM, Peter Zijlstra  wrote:
> > > On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote:
> > >> There is a caveat, however. Certain applications running in virtual-8086
> > >> mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and
> > >> SLDT instructions for legitimate reasons. In order to keep such
> > >> applications working, UMIP must be disabled/enabled when entering/exiting
> > >> virtual-8086 mode.
> > >
> > > Would it not be better to emulate these instructions for them? What way
> > > we can verify they're not malicious.
> > 
> > Forget malice -- if they are really needed for some silly vm86-using
> > program, let's trap them and emulate them so they return dummy values.
> 
> handle_vm86_fault() already does instruction emulation, so adding the few
> bits there is the right thing to do. Then we just can enable UMIP
> unconditionally and be done with it.

Ah. I didn't think about that. It make sense to me. I will rework this
series with this approach.
> 
> Thanks,
> 
>   tglx

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Thomas Gleixner]

On Tue, 8 Nov 2016, Andy Lutomirski wrote:
> On Tue, Nov 8, 2016 at 5:16 AM, Peter Zijlstra  wrote:
> > On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote:
> >> There is a caveat, however. Certain applications running in virtual-8086
> >> mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and
> >> SLDT instructions for legitimate reasons. In order to keep such
> >> applications working, UMIP must be disabled/enabled when entering/exiting
> >> virtual-8086 mode.
> >
> > Would it not be better to emulate these instructions for them? What way
> > we can verify they're not malicious.
> 
> Forget malice -- if they are really needed for some silly vm86-using
> program, let's trap them and emulate them so they return dummy values.

handle_vm86_fault() already does instruction emulation, so adding the few
bits there is the right thing to do. Then we just can enable UMIP
unconditionally and be done with it.

Thanks,

tglx

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Thomas Gleixner]

On Tue, 8 Nov 2016, Andy Lutomirski wrote:
> On Tue, Nov 8, 2016 at 5:16 AM, Peter Zijlstra  wrote:
> > On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote:
> >> There is a caveat, however. Certain applications running in virtual-8086
> >> mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and
> >> SLDT instructions for legitimate reasons. In order to keep such
> >> applications working, UMIP must be disabled/enabled when entering/exiting
> >> virtual-8086 mode.
> >
> > Would it not be better to emulate these instructions for them? What way
> > we can verify they're not malicious.
> 
> Forget malice -- if they are really needed for some silly vm86-using
> program, let's trap them and emulate them so they return dummy values.

handle_vm86_fault() already does instruction emulation, so adding the few
bits there is the right thing to do. Then we just can enable UMIP
unconditionally and be done with it.

Thanks,

tglx

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Tue, Nov 8, 2016 at 5:16 AM, Peter Zijlstra  wrote:
> On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote:
>> There is a caveat, however. Certain applications running in virtual-8086
>> mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and
>> SLDT instructions for legitimate reasons. In order to keep such
>> applications working, UMIP must be disabled/enabled when entering/exiting
>> virtual-8086 mode.
>
> Would it not be better to emulate these instructions for them? What way
> we can verify they're not malicious.

Forget malice -- if they are really needed for some silly vm86-using
program, let's trap them and emulate them so they return dummy values.

Also, keep in mind that vm86 is already effectively gated behind a
sysctl for non-root.  I think the default should be that, if root has
enabled vm86, it should work.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Tue, Nov 8, 2016 at 5:16 AM, Peter Zijlstra  wrote:
> On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote:
>> There is a caveat, however. Certain applications running in virtual-8086
>> mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and
>> SLDT instructions for legitimate reasons. In order to keep such
>> applications working, UMIP must be disabled/enabled when entering/exiting
>> virtual-8086 mode.
>
> Would it not be better to emulate these instructions for them? What way
> we can verify they're not malicious.

Forget malice -- if they are really needed for some silly vm86-using
program, let's trap them and emulate them so they return dummy values.

Also, keep in mind that vm86 is already effectively gated behind a
sysctl for non-root.  I think the default should be that, if root has
enabled vm86, it should work.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Peter Zijlstra]

On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote:
> There is a caveat, however. Certain applications running in virtual-8086
> mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and
> SLDT instructions for legitimate reasons. In order to keep such
> applications working, UMIP must be disabled/enabled when entering/exiting
> virtual-8086 mode. 

Would it not be better to emulate these instructions for them? What way
we can verify they're not malicious.

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Peter Zijlstra]

On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote:
> There is a caveat, however. Certain applications running in virtual-8086
> mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and
> SLDT instructions for legitimate reasons. In order to keep such
> applications working, UMIP must be disabled/enabled when entering/exiting
> virtual-8086 mode. 

Would it not be better to emulate these instructions for them? What way
we can verify they're not malicious.