Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

04.04.2017 05:05, Ricardo Neri пишет:

On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote:

30.03.2017 08:14, Ricardo Neri пишет:

You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.

But emulation is still needed for SMSW, right?

Likely so.
If you want, I can enable the logging of this command
and see if it is used by some of the DOS programs I have.

It would be great if you could do that, if you don't mind.

OK, scheduled to the week-end.
I'll let you know.

Thanks!

OK, done the testing.
It appears smsw is used in v86 by windows-3.1 and dos4gw
at the very least, and these are the "major" apps. So doing
without a fixup in v86 will not go unnoticed. Unfortunately
this also means that KVM-vm86 should be properly tested.
I have also found a weird program that does SGDT under
v86. This causes "ERROR: SGDT not implemented" under
dosemu, but the prog still works fine as it obviously does
not care about the results. This app can easily be broken
of course, if that makes any sense (likely not).

Thanks for inputs! Then it seems that we will need emulation for sgdt
and smsw.

I wouldn't claim we need an emulation of sgdt. One
or 2 exotic apps do not count much, considering the
overall small usage of dosemu and an easiness of
re-adding them to dosemu itself.
So if it makes any sense to not add it for vm86, then
please leave it omitted. However it seems Andy wants
an overall completeness here, lot let me just say I'll be
fine with either option.


  Perhaps sidt?

If only for overall completeness.
If it makes any sense to, please leave it omitted.


  sldt and str will not need emulation in either
protected mode or virtual-8086 mode. At a later stage I can look into
working in the syscall as Andy proposes.

I will also look into the kvm-v86 path for dosemu2.

It seems we have an agreement :) Do we?

Yes, fine with me.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Alexandre Julliard]

Ricardo Neri  writes:

> On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote:
>> Ricardo Neri  writes:
>> 
>> > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote:
>> >> 30.03.2017 08:14, Ricardo Neri пишет:
>> >> In fact, smsw has an interesting property, which is that
>> >> no one will ever want to disable its in-kernel emulation
>> >> to provide its own.
>> >> So while I'll try to estimate its usage, emulating it in kernel
>> >> will not be that problematic in either case.
>> >
>> > Ah good to know!
>> >
>> >> As for protected mode, if wine only needs sgdt/sidt, then
>> >> again, no one will want to disable its emulation. Not the
>> >> case with sldt, but AFAICS wine doesn't need sldt, and so
>> >> we can leave sldt without a fixups. Is my understanding
>> >> correct?
>> >
>> > This is my understanding as well. I could not find any use of sldt in
>> > wine. Alexandre, would you mind confirming?
>> 
>> Some versions of the Themida software protection are known to use sldt
>> as part of the virtual machine detection code [1]. The check currently
>> fails because it expects the LDT to be zero, so the app is already
>> broken, but sldt segfaulting would still cause a crash where there
>> wasn't one before.
>> 
>> However, I'm only aware of one application using this, and being able to
>> catch and emulate sldt ourselves would actually give us a chance to fix
>> this app in newer Wine versions, so I'm not opposed to having it
>> segfault.
>
> Great! Then this is in line with what we are aiming to do with dosemu2:
> not emulate str and sldt.
>> 
>> In fact it would be nice to be able to make sidt/sgdt/etc. segfault
>> too. I know a new syscall is a pain, but as far as Wine is concerned,
>> being able to opt out from any emulation would be potentially useful.
>
> I see. I guess for now there should not be a problem with emulating
> sidt/sgdt/smsw, right? In this way we don't break current versions of
> winehq and programs using it. In a phase two we can introduce the
> syscall so that kernel fixups can be disabled. Does this make sense?

Yes, that makes sense.

-- 
Alexandre Julliard
julli...@winehq.org
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote:
> Ricardo Neri  writes:
> 
> > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote:
> >> 30.03.2017 08:14, Ricardo Neri пишет:
> >>  But at least dosemu implements it, so probably it is needed.
> >> >>> Right.
> >> >>>
> >>  Of course if it is used by one of 100 DOS progs, then there
> >>  is an option to just add its support to dosemu2 and pretend
> >>  the compatibility problems did not exist. :)
> >> >>> Do you mean relaying the GP fault to dosemu instead of trapping it and
> >> >>> emulating it in the kernel?
> >> >> Yes, that would be optimal if this does not severely break
> >> >> the current setups. If we can find out that smsw is not in
> >> >> the real use, we can probably do exactly that.
> >> >> But other
> >> >> instructions are not in real use in v86 for sure, so I
> >> >> wouldn't be adding the explicit test-cases to the kernel
> >> >> that will make you depend on some particular behaviour
> >> >> that no one may need.
> >> >> My objection was that we shouldn't
> >> >> write tests before we know exactly how we want this to work.
> >> > OK, if only SMSW is used then I'll keep the emulation for SMSW only.
> >> In fact, smsw has an interesting property, which is that
> >> no one will ever want to disable its in-kernel emulation
> >> to provide its own.
> >> So while I'll try to estimate its usage, emulating it in kernel
> >> will not be that problematic in either case.
> >
> > Ah good to know!
> >
> >> As for protected mode, if wine only needs sgdt/sidt, then
> >> again, no one will want to disable its emulation. Not the
> >> case with sldt, but AFAICS wine doesn't need sldt, and so
> >> we can leave sldt without a fixups. Is my understanding
> >> correct?
> >
> > This is my understanding as well. I could not find any use of sldt in
> > wine. Alexandre, would you mind confirming?
> 
> Some versions of the Themida software protection are known to use sldt
> as part of the virtual machine detection code [1]. The check currently
> fails because it expects the LDT to be zero, so the app is already
> broken, but sldt segfaulting would still cause a crash where there
> wasn't one before.
> 
> However, I'm only aware of one application using this, and being able to
> catch and emulate sldt ourselves would actually give us a chance to fix
> this app in newer Wine versions, so I'm not opposed to having it
> segfault.

Great! Then this is in line with what we are aiming to do with dosemu2:
not emulate str and sldt.
> 
> In fact it would be nice to be able to make sidt/sgdt/etc. segfault
> too. I know a new syscall is a pain, but as far as Wine is concerned,
> being able to opt out from any emulation would be potentially useful.

I see. I guess for now there should not be a problem with emulating
sidt/sgdt/smsw, right? In this way we don't break current versions of
winehq and programs using it. In a phase two we can introduce the
syscall so that kernel fixups can be disabled. Does this make sense?

Thanks and BR,
Ricardo

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[H. Peter Anvin]

,linux-msdos@vger.kernel.org,wine-de...@winehq.org
From: h...@zytor.com
Message-ID: <3fd12652-aa83-4d73-9914-bba089e58...@zytor.com>

On April 1, 2017 6:08:43 AM PDT, Stas Sergeev  wrote:
>30.03.2017 08:14, Ricardo Neri пишет:
>>> You know the wine's
>>> requirements now - they are very small. And
>>> dosemu doesn't need anything at all but smsw.
>>> And even smsw is very rare.
>> But emulation is still needed for SMSW, right?
> Likely so.
> If you want, I can enable the logging of this command
> and see if it is used by some of the DOS programs I have.
 It would be great if you could do that, if you don't mind.
>>> OK, scheduled to the week-end.
>>> I'll let you know.
>> Thanks!
>OK, done the testing.
>It appears smsw is used in v86 by windows-3.1 and dos4gw
>at the very least, and these are the "major" apps. So doing
>without a fixup in v86 will not go unnoticed. Unfortunately
>this also means that KVM-vm86 should be properly tested.
>I have also found a weird program that does SGDT under
>v86. This causes "ERROR: SGDT not implemented" under
>dosemu, but the prog still works fine as it obviously does
>not care about the results. This app can easily be broken
>of course, if that makes any sense (likely not).

Using SMSW to detect v86 mode is relatively common.  pushf hides the VM flag, 
but SMSW is available, providing the v86 virtualization hole.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

30.03.2017 08:14, Ricardo Neri пишет:

You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.

But emulation is still needed for SMSW, right?

Likely so.
If you want, I can enable the logging of this command
and see if it is used by some of the DOS programs I have.

It would be great if you could do that, if you don't mind.

OK, scheduled to the week-end.
I'll let you know.

Thanks!

OK, done the testing.
It appears smsw is used in v86 by windows-3.1 and dos4gw
at the very least, and these are the "major" apps. So doing
without a fixup in v86 will not go unnoticed. Unfortunately
this also means that KVM-vm86 should be properly tested.
I have also found a weird program that does SGDT under
v86. This causes "ERROR: SGDT not implemented" under
dosemu, but the prog still works fine as it obviously does
not care about the results. This app can easily be broken
of course, if that makes any sense (likely not).
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Fri, Mar 31, 2017 at 2:26 PM, Stas Sergeev  wrote:
> 31.03.2017 17:11, Alexandre Julliard пишет:
>>
>> In fact it would be nice to be able to make sidt/sgdt/etc. segfault
>> too. I know a new syscall is a pain,
>
> Maybe arch_prctl() then?

I still like my idea of a generic mechanism to turn off
backwards-compatibility things.  After all, hardened programs should
turn off UMIP fixups entirely.  They should also turn off vsyscall
emulation entirely, and I see no reason that these mechanisms should
be different.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

31.03.2017 17:11, Alexandre Julliard пишет:

In fact it would be nice to be able to make sidt/sgdt/etc. segfault
too. I know a new syscall is a pain,

Maybe arch_prctl() then?
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Alexandre Julliard]

Ricardo Neri  writes:

> On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote:
>> 30.03.2017 08:14, Ricardo Neri пишет:
>>  But at least dosemu implements it, so probably it is needed.
>> >>> Right.
>> >>>
>>  Of course if it is used by one of 100 DOS progs, then there
>>  is an option to just add its support to dosemu2 and pretend
>>  the compatibility problems did not exist. :)
>> >>> Do you mean relaying the GP fault to dosemu instead of trapping it and
>> >>> emulating it in the kernel?
>> >> Yes, that would be optimal if this does not severely break
>> >> the current setups. If we can find out that smsw is not in
>> >> the real use, we can probably do exactly that.
>> >> But other
>> >> instructions are not in real use in v86 for sure, so I
>> >> wouldn't be adding the explicit test-cases to the kernel
>> >> that will make you depend on some particular behaviour
>> >> that no one may need.
>> >> My objection was that we shouldn't
>> >> write tests before we know exactly how we want this to work.
>> > OK, if only SMSW is used then I'll keep the emulation for SMSW only.
>> In fact, smsw has an interesting property, which is that
>> no one will ever want to disable its in-kernel emulation
>> to provide its own.
>> So while I'll try to estimate its usage, emulating it in kernel
>> will not be that problematic in either case.
>
> Ah good to know!
>
>> As for protected mode, if wine only needs sgdt/sidt, then
>> again, no one will want to disable its emulation. Not the
>> case with sldt, but AFAICS wine doesn't need sldt, and so
>> we can leave sldt without a fixups. Is my understanding
>> correct?
>
> This is my understanding as well. I could not find any use of sldt in
> wine. Alexandre, would you mind confirming?

Some versions of the Themida software protection are known to use sldt
as part of the virtual machine detection code [1]. The check currently
fails because it expects the LDT to be zero, so the app is already
broken, but sldt segfaulting would still cause a crash where there
wasn't one before.

However, I'm only aware of one application using this, and being able to
catch and emulate sldt ourselves would actually give us a chance to fix
this app in newer Wine versions, so I'm not opposed to having it
segfault.

In fact it would be nice to be able to make sidt/sgdt/etc. segfault
too. I know a new syscall is a pain, but as far as Wine is concerned,
being able to opt out from any emulation would be potentially useful.

[1] https://www.winehq.org/pipermail/wine-bugs/2008-February/094470.html

-- 
Alexandre Julliard
julli...@winehq.org
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote:
> 30.03.2017 08:14, Ricardo Neri пишет:
>  But at least dosemu implements it, so probably it is needed.
> >>> Right.
> >>>
>  Of course if it is used by one of 100 DOS progs, then there
>  is an option to just add its support to dosemu2 and pretend
>  the compatibility problems did not exist. :)
> >>> Do you mean relaying the GP fault to dosemu instead of trapping it and
> >>> emulating it in the kernel?
> >> Yes, that would be optimal if this does not severely break
> >> the current setups. If we can find out that smsw is not in
> >> the real use, we can probably do exactly that.
> >> But other
> >> instructions are not in real use in v86 for sure, so I
> >> wouldn't be adding the explicit test-cases to the kernel
> >> that will make you depend on some particular behaviour
> >> that no one may need.
> >> My objection was that we shouldn't
> >> write tests before we know exactly how we want this to work.
> > OK, if only SMSW is used then I'll keep the emulation for SMSW only.
> In fact, smsw has an interesting property, which is that
> no one will ever want to disable its in-kernel emulation
> to provide its own.
> So while I'll try to estimate its usage, emulating it in kernel
> will not be that problematic in either case.

Ah good to know!

> As for protected mode, if wine only needs sgdt/sidt, then
> again, no one will want to disable its emulation. Not the
> case with sldt, but AFAICS wine doesn't need sldt, and so
> we can leave sldt without a fixups. Is my understanding
> correct?

This is my understanding as well. I could not find any use of sldt in
wine. Alexandre, would you mind confirming?

> In this case, I suppose, we are very well on a way to avoid
> the extra syscalls to toggle the emulation features.

Great! Then I will keep the emulation for sgdt, sidt, and smsw but not
for str and sldt; for both vm86 and protected mode. This seems to be the
agreement.

Thanks and BR,
Ricardo


--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

30.03.2017 08:14, Ricardo Neri пишет:

But at least dosemu implements it, so probably it is needed.

Right.


Of course if it is used by one of 100 DOS progs, then there
is an option to just add its support to dosemu2 and pretend
the compatibility problems did not exist. :)

Do you mean relaying the GP fault to dosemu instead of trapping it and
emulating it in the kernel?

Yes, that would be optimal if this does not severely break
the current setups. If we can find out that smsw is not in
the real use, we can probably do exactly that.
But other
instructions are not in real use in v86 for sure, so I
wouldn't be adding the explicit test-cases to the kernel
that will make you depend on some particular behaviour
that no one may need.
My objection was that we shouldn't
write tests before we know exactly how we want this to work.

OK, if only SMSW is used then I'll keep the emulation for SMSW only.

In fact, smsw has an interesting property, which is that
no one will ever want to disable its in-kernel emulation
to provide its own.
So while I'll try to estimate its usage, emulating it in kernel
will not be that problematic in either case.
As for protected mode, if wine only needs sgdt/sidt, then
again, no one will want to disable its emulation. Not the
case with sldt, but AFAICS wine doesn't need sldt, and so
we can leave sldt without a fixups. Is my understanding
correct?
In this case, I suppose, we are very well on a way to avoid
the extra syscalls to toggle the emulation features.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Wed, 2017-03-29 at 23:55 +0300, Stas Sergeev wrote:
> 29.03.2017 07:38, Ricardo Neri пишет:
> >> Probably you could also remove
> >> the sldt and str emulation for protected mode, because,
> >> as I understand from this thread, wine does not
> >> need those.
> > I see. I would lean on keeping the emulation because I already
> > implemented it :), for completeness, and because it is performed in a
> > single switch. The bulk of the emulation code deals with operands.
> But this is not for free.
> As Andy said, you will then need a syscall and
> a feature mask to be able to disable this emulation.
> And AFAIK you haven't implemented that yet, so
> there is something to consider.

Right, I see your point.

>  You know the wine's
>  requirements now - they are very small. And
>  dosemu doesn't need anything at all but smsw.
>  And even smsw is very rare.
> >>> But emulation is still needed for SMSW, right?
> >> Likely so.
> >> If you want, I can enable the logging of this command
> >> and see if it is used by some of the DOS programs I have.
> > It would be great if you could do that, if you don't mind.
> OK, scheduled to the week-end.
> I'll let you know.

Thanks!

> 
> >> But at least dosemu implements it, so probably it is needed.
> > Right.
> >
> >> Of course if it is used by one of 100 DOS progs, then there
> >> is an option to just add its support to dosemu2 and pretend
> >> the compatibility problems did not exist. :)
> > Do you mean relaying the GP fault to dosemu instead of trapping it and
> > emulating it in the kernel?
> Yes, that would be optimal if this does not severely break
> the current setups. If we can find out that smsw is not in
> the real use, we can probably do exactly that. 
> But other
> instructions are not in real use in v86 for sure, so I
> wouldn't be adding the explicit test-cases to the kernel
> that will make you depend on some particular behaviour
> that no one may need.

> My objection was that we shouldn't
> write tests before we know exactly how we want this to work.
OK, if only SMSW is used then I'll keep the emulation for SMSW only.


--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

11.03.2017 02:59, Ricardo Neri пишет:

On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:


Why would you need one?
Or do you really want to allow these instructions
in v86 by the means of emulation? If so - this wasn't
clearly stated in the patch description, neither it was
properly discussed, it seems.

It str and sldt can be emulated in vm86 but as Andy mention, the
behavior sould be the same with and without emulation.

Why would you do that?
I looked up the dosemu2 CPU simulator code that
is used under x86-64. It says this:
---
CODE_FLUSH();
if (REALMODE()) goto illegal_op;
PC += ModRMSim(PC+1, mode) + 1;
error("SLDT not implemented\n");
break;
case 1: /* STR */
/* Store Task Register */
CODE_FLUSH();
if (REALMODE()) goto illegal_op;
PC += ModRMSim(PC+1, mode) + 1;
error("STR not implemented\n");
break;
...
case 0: /* SGDT */
/* Store Global Descriptor Table 
Register */
PC++; PC += ModRM(opc, PC, 
mode|DATA16|MSTORE);

error("SGDT not implemented\n");
break;
case 1: /* SIDT */
/* Store Interrupt Descriptor Table 
Register */
PC++; PC += ModRM(opc, PC, 
mode|DATA16|MSTORE);

error("SIDT not implemented\n");
break;
---

It only implements smsw.
So maybe you can make your code much
simpler and remove the unneeded emulation?
Same is for prot mode. You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

29.03.2017 07:38, Ricardo Neri пишет:

Probably you could also remove
the sldt and str emulation for protected mode, because,
as I understand from this thread, wine does not
need those.

I see. I would lean on keeping the emulation because I already
implemented it :), for completeness, and because it is performed in a
single switch. The bulk of the emulation code deals with operands.

But this is not for free.
As Andy said, you will then need a syscall and
a feature mask to be able to disable this emulation.
And AFAIK you haven't implemented that yet, so
there is something to consider.


You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.

But emulation is still needed for SMSW, right?

Likely so.
If you want, I can enable the logging of this command
and see if it is used by some of the DOS programs I have.

It would be great if you could do that, if you don't mind.

OK, scheduled to the week-end.
I'll let you know.


But at least dosemu implements it, so probably it is needed.

Right.


Of course if it is used by one of 100 DOS progs, then there
is an option to just add its support to dosemu2 and pretend
the compatibility problems did not exist. :)

Do you mean relaying the GP fault to dosemu instead of trapping it and
emulating it in the kernel?

Yes, that would be optimal if this does not severely break
the current setups. If we can find out that smsw is not in
the real use, we can probably do exactly that. But other
instructions are not in real use in v86 for sure, so I
wouldn't be adding the explicit test-cases to the kernel
that will make you depend on some particular behaviour
that no one may need. My objection was that we shouldn't
write tests before we know exactly how we want this to work.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2017-03-28 at 12:38 +0300, Stas Sergeev wrote:
> 28.03.2017 02:46, Ricardo Neri пишет:
> > On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote:
> >> 11.03.2017 02:59, Ricardo Neri пишет:
> >>> On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
> >>>
>  Why would you need one?
>  Or do you really want to allow these instructions
>  in v86 by the means of emulation? If so - this wasn't
>  clearly stated in the patch description, neither it was
>  properly discussed, it seems.
> >>> It str and sldt can be emulated in vm86 but as Andy mention, the
> >>> behavior sould be the same with and without emulation.
> >> Why would you do that?
> >> I looked up the dosemu2 CPU simulator code that
> >> is used under x86-64. It says this:
> > Stas, I apologize for the delayed reply; I missed your e-mail.
> >> It only implements smsw.
> >> So maybe you can make your code much
> >> simpler and remove the unneeded emulation?
> >> Same is for prot mode.
> > Do you mean the unneeded emulation for SLDT and STR?
> Not quite, I meant also sgdt and sidt in vm86.
> Yes that it will be a somewhat "incompatible" change,
> but if there is nothing to stay compatible with,
> then why to worry?

My idea of compatibility was to have the emulation code behave exactly
as a processor without UMIP :)

> Probably you could also remove
> the sldt and str emulation for protected mode, because,
> as I understand from this thread, wine does not
> need those.

I see. I would lean on keeping the emulation because I already
implemented it :), for completeness, and because it is performed in a
single switch. The bulk of the emulation code deals with operands.
> 
> Note that these days dosemu2 uses v86 mode set
> up under kvm rather than vm86(). Your patches
> affect that the same way as they do for vm86()
> syscall, or can there be some differences?
My code does not touch kvm at all. I would need to assess how kvm will
behave.
> Or should
> the UMIP be enabled under kvm by hands?
There was an attempt to emulate UMIP that was submitted a while ago:
https://lkml.org/lkml/2016/7/12/644

> 
> >> You know the wine's
> >> requirements now - they are very small. And
> >> dosemu doesn't need anything at all but smsw.
> >> And even smsw is very rare.
> > But emulation is still needed for SMSW, right?
> Likely so.
> If you want, I can enable the logging of this command
> and see if it is used by some of the DOS programs I have.

It would be great if you could do that, if you don't mind.
> But at least dosemu implements it, so probably it is needed.

Right.

> Of course if it is used by one of 100 DOS progs, then there
> is an option to just add its support to dosemu2 and pretend
> the compatibility problems did not exist. :)
Do you mean relaying the GP fault to dosemu instead of trapping it and
emulating it in the kernel?

Thanks and BR,
Ricardo

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Tue, 2017-03-14 at 00:25 +0300, Stas Sergeev wrote:
> 11.03.2017 02:59, Ricardo Neri пишет:
> > On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
> >
> >> Why would you need one?
> >> Or do you really want to allow these instructions
> >> in v86 by the means of emulation? If so - this wasn't
> >> clearly stated in the patch description, neither it was
> >> properly discussed, it seems.
> > It str and sldt can be emulated in vm86 but as Andy mention, the
> > behavior sould be the same with and without emulation.
> Why would you do that?
> I looked up the dosemu2 CPU simulator code that
> is used under x86-64. It says this:

Stas, I apologize for the delayed reply; I missed your e-mail. 
> ---
>  CODE_FLUSH();
>  if (REALMODE()) goto illegal_op;
>  PC += ModRMSim(PC+1, mode) + 1;
>  error("SLDT not implemented\n");
>  break;
>  case 1: /* STR */
>  /* Store Task Register */
>  CODE_FLUSH();
>  if (REALMODE()) goto illegal_op;
>  PC += ModRMSim(PC+1, mode) + 1;
>  error("STR not implemented\n");
>  break;
> ...
>  case 0: /* SGDT */
>  /* Store Global Descriptor Table 
> Register */
>  PC++; PC += ModRM(opc, PC, 
> mode|DATA16|MSTORE);
>  error("SGDT not implemented\n");
>  break;
>  case 1: /* SIDT */
>  /* Store Interrupt Descriptor Table 
> Register */
>  PC++; PC += ModRM(opc, PC, 
> mode|DATA16|MSTORE);
>  error("SIDT not implemented\n");
>  break;
> ---
> 
> It only implements smsw.
> So maybe you can make your code much
> simpler and remove the unneeded emulation?
> Same is for prot mode.

Do you mean the unneeded emulation for SLDT and STR?

> You know the wine's
> requirements now - they are very small. And
> dosemu doesn't need anything at all but smsw.
> And even smsw is very rare.
But emulation is still needed for SMSW, right?

The majority of my patches deal with computing the effective based on
the instruction operands and linear addresses based on the effective
address and the segment descriptor. Only two or three patches deal with
identifying particular UMIP-protected instructions. Not having to worry
about STR and SLDT in vm86 could simplify things a bit, though.

Thanks and BR,
Ricardo


--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Fri, 2017-03-10 at 06:17 -0800, Andy Lutomirski wrote:
> On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeev  wrote:
> > 10.03.2017 05:39, Andy Lutomirski пишет:
> >
> >> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev  wrote:
> >>>
> >>> 09.03.2017 04:15, Ricardo Neri пишет:
> >>>
>  On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
> >
> > On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev  wrote:
> >>
> >> 08.03.2017 19:06, Andy Lutomirski пишет:
> >>>
> >>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:
> 
>  08.03.2017 03:32, Ricardo Neri пишет:
> >
> > These are the instructions covered by UMIP:
> > * SGDT - Store Global Descriptor Table
> > * SIDT - Store Interrupt Descriptor Table
> > * SLDT - Store Local Descriptor Table
> > * SMSW - Store Machine Status Word
> > * STR - Store Task Register
> >
> > This patchset initially treated tasks running in virtual-8086
> >
> > mode as a
> >
> > special case. However, I received clarification that DOSEMU[8]
> >
> > does not
> >
> > support applications that use these instructions.
> >>>
> >>> Can you remind me what was special about it?  It looks like you
> >
> > still
> >>>
> >>> emulate them in v8086 mode.
> >>
> >> Indeed, sorry, I meant prot mode here. :)
> >> So I wonder what was cited to be special about v86.
> 
>  Initially my patches disabled UMIP on virtual-8086 instructions, without
>  regards of protected mode (i.e., UMIP was always enabled). I didn't have
>  emulation at the time. Then, I added emulation code that now covers
>  protected and virtual-8086 modes. I guess it is not special anymore.
> >>>
> >>> But isn't SLDT just throw UD in v86?
> >>> How does UMIP affect this? How does your patch affect
> >>> this?
> >>
> >> Er, right.  Ricardo, your code may need fixing.  But don't you have a
> >> test case for this?
> >
> > Why would you need one?
> > Or do you really want to allow these instructions
> > in v86 by the means of emulation? If so - this wasn't
> > clearly stated in the patch description, neither it was
> > properly discussed, it seems.
> 
> What I meant was: if the patches incorrectly started making these
> instructions work in vm86 mode where they used to cause a vm86 exit,
> then that's a bug that the selftest should have caught.

Yes, this is the case. I will fix this behavior... and update the test
cases.


--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Sat, 2017-03-11 at 02:58 +0300, Stas Sergeev wrote:
> 11.03.2017 02:47, Ricardo Neri пишет:
> >>
>  It doesn't need to be a matter of this particular
>  patch set, i.e. this proposal should not trigger a
>  v7 resend of all 21 patches. :) But it would be useful
>  for the future development of dosemu2.
> >>> Would dosemu2 use 32-bit processes in order to keep segmentation? If it
> >>> could use 64-bit processes, emulation is not used in this case and the
> >>> SIGSEGV is delivered to user space.
> >> It does use the mix: 64bit process but some segments
> >> are 32bit for DOS code.
> > Do you mean that dosemu2 will start as a 64-bit process and will jump to
> > 32-bit code segments?
> Yes, so the offending insns are executed only in 32bit
> and 16bit segments, even if the process itself is 64bit.
> I guess you handle 16bit segments same as 32bit ones.

I have code to handle 16-bit and 32-bit address encodings differently.
Segmentation is used if !user_64bit_mode(regs). In such a case, the
emulation code will check the segment descriptor D flag and the
address-size overrides prefix to determine the address size and use
16-bit or 32-bit address encodings as applicable.

> 
> >   My emulation code should work in this case as it
> > will use segmentation in 32-bit code descriptors. Is there anything else
> > needed?
> If I understand you correctly, you are saying that SLDT
> executed in 64bit code segment, will inevitably segfault
> to userspace. 
Correct.

> If this is the case and it makes your code
> simpler, then its perfectly fine with me as dosemu does
> not do this and the 64bit DOS progs are not anticipated.

But if 32-bit or 16-bit code segments are used emulation will be used.

Thanks and BR,
Ricardo


--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:
> 10.03.2017 05:39, Andy Lutomirski пишет:
> > On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev  wrote:
> >> 09.03.2017 04:15, Ricardo Neri пишет:
> >>
> >>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
>  On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev  wrote:
> > 08.03.2017 19:06, Andy Lutomirski пишет:
> >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:
> >>> 08.03.2017 03:32, Ricardo Neri пишет:
>  These are the instructions covered by UMIP:
>  * SGDT - Store Global Descriptor Table
>  * SIDT - Store Interrupt Descriptor Table
>  * SLDT - Store Local Descriptor Table
>  * SMSW - Store Machine Status Word
>  * STR - Store Task Register
> 
>  This patchset initially treated tasks running in virtual-8086
>  mode as a
>  special case. However, I received clarification that DOSEMU[8]
>  does not
>  support applications that use these instructions.
> >> Can you remind me what was special about it?  It looks like you
>  still
> >> emulate them in v8086 mode.
> > Indeed, sorry, I meant prot mode here. :)
> > So I wonder what was cited to be special about v86.
> >>> Initially my patches disabled UMIP on virtual-8086 instructions, without
> >>> regards of protected mode (i.e., UMIP was always enabled). I didn't have
> >>> emulation at the time. Then, I added emulation code that now covers
> >>> protected and virtual-8086 modes. I guess it is not special anymore.
> >> But isn't SLDT just throw UD in v86?
> >> How does UMIP affect this? How does your patch affect
> >> this?
> > Er, right.  Ricardo, your code may need fixing.  But don't you have a
> > test case for this?
> Why would you need one?
> Or do you really want to allow these instructions
> in v86 by the means of emulation? If so - this wasn't
> clearly stated in the patch description, neither it was
> properly discussed, it seems.

It str and sldt can be emulated in vm86 but as Andy mention, the
behavior sould be the same with and without emulation.

Thanks and BR,
Ricardo


--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

11.03.2017 02:47, Ricardo Neri пишет:



It doesn't need to be a matter of this particular
patch set, i.e. this proposal should not trigger a
v7 resend of all 21 patches. :) But it would be useful
for the future development of dosemu2.

Would dosemu2 use 32-bit processes in order to keep segmentation? If it
could use 64-bit processes, emulation is not used in this case and the
SIGSEGV is delivered to user space.

It does use the mix: 64bit process but some segments
are 32bit for DOS code.

Do you mean that dosemu2 will start as a 64-bit process and will jump to
32-bit code segments?

Yes, so the offending insns are executed only in 32bit
and 16bit segments, even if the process itself is 64bit.
I guess you handle 16bit segments same as 32bit ones.


  My emulation code should work in this case as it
will use segmentation in 32-bit code descriptors. Is there anything else
needed?

If I understand you correctly, you are saying that SLDT
executed in 64bit code segment, will inevitably segfault
to userspace. If this is the case and it makes your code
simpler, then its perfectly fine with me as dosemu does
not do this and the 64bit DOS progs are not anticipated.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Thu, 2017-03-09 at 18:39 -0800, Andy Lutomirski wrote:
> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev  wrote:
> > 09.03.2017 04:15, Ricardo Neri пишет:
> >
> >> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
> >>>
> >>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev  wrote:
> 
>  08.03.2017 19:06, Andy Lutomirski пишет:
> >
> > On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:
> >>
> >> 08.03.2017 03:32, Ricardo Neri пишет:
> >>>
> >>> These are the instructions covered by UMIP:
> >>> * SGDT - Store Global Descriptor Table
> >>> * SIDT - Store Interrupt Descriptor Table
> >>> * SLDT - Store Local Descriptor Table
> >>> * SMSW - Store Machine Status Word
> >>> * STR - Store Task Register
> >>>
> >>> This patchset initially treated tasks running in virtual-8086
> >>>
> >>> mode as a
> >>>
> >>> special case. However, I received clarification that DOSEMU[8]
> >>>
> >>> does not
> >>>
> >>> support applications that use these instructions.
> >
> > Can you remind me what was special about it?  It looks like you
> >>>
> >>> still
> >
> > emulate them in v8086 mode.
> 
>  Indeed, sorry, I meant prot mode here. :)
>  So I wonder what was cited to be special about v86.
> >>
> >> Initially my patches disabled UMIP on virtual-8086 instructions, without
> >> regards of protected mode (i.e., UMIP was always enabled). I didn't have
> >> emulation at the time. Then, I added emulation code that now covers
> >> protected and virtual-8086 modes. I guess it is not special anymore.
> >
> > But isn't SLDT just throw UD in v86?
> > How does UMIP affect this? How does your patch affect
> > this?
> 
> Er, right.  Ricardo, your code may need fixing.  But don't you have a
> test case for this?  The behavior should be the same with and without
> your patches applied.  The exception is #UD, not #GP, so maybe your
> code just never executes in the vm86 case.

Ouch! Yes, I am afraid my code will attempt to emulate sldt in vm86
mode. The test cases that I have for vm86 are only for the instructions
that are valid in vm86: smsw, sidt and sgdt.

I will add test cases for str and sldt and make sure that a #UD is
issued.

Would this trigger a v7 series?

Thanks and BR,
Ricardo
> 
> --Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Fri, 2017-03-10 at 01:01 +0300, Stas Sergeev wrote:
> 09.03.2017 03:46, Ricardo Neri пишет:
> > On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote:
> >> 08.03.2017 03:32, Ricardo Neri пишет:
> >>> These are the instructions covered by UMIP:
> >>> * SGDT - Store Global Descriptor Table
> >>> * SIDT - Store Interrupt Descriptor Table
> >>> * SLDT - Store Local Descriptor Table
> >>> * SMSW - Store Machine Status Word
> >>> * STR - Store Task Register
> >>>
> >>> This patchset initially treated tasks running in virtual-8086 mode as a
> >>> special case. However, I received clarification that DOSEMU[8] does not
> >>> support applications that use these instructions.
> >> Yes, this is the case.
> >> But at least in the past there was an attempt to
> >> support SLDT as it is used by an ancient pharlap
> >> DOS extender (currently unsupported by dosemu1/2).
> >> So how difficult would it be to add an optional
> >> possibility of delivering such SIGSEGV to userspace
> >> so that the kernel's dummy emulation can be overridden?
> > I suppose a umip=noemulation kernel parameter could be added in this
> > case.
> Why?
> It doesn't need to be global: the app should be
> able to change that on its own. Note that no app currently
> requires this, so its just for the future, and in the
> future the app can start using the new API for this,
> if you provide one.

Right, I missed this detail. Then, yes the API should allow only one app
to relay the SIGSEGV.
> 
> 
> >> It doesn't need to be a matter of this particular
> >> patch set, i.e. this proposal should not trigger a
> >> v7 resend of all 21 patches. :) But it would be useful
> >> for the future development of dosemu2.
> > Would dosemu2 use 32-bit processes in order to keep segmentation? If it
> > could use 64-bit processes, emulation is not used in this case and the
> > SIGSEGV is delivered to user space.
> It does use the mix: 64bit process but some segments
> are 32bit for DOS code.

Do you mean that dosemu2 will start as a 64-bit process and will jump to
32-bit code segments? My emulation code should work in this case as it
will use segmentation in 32-bit code descriptors. Is there anything else
needed?

Thanks and BR,
Ricardo

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

11.03.2017 00:04, Andy Lutomirski пишет:

On Fri, Mar 10, 2017 at 2:30 AM, Stas Sergeev  wrote:

10.03.2017 05:41, Andy Lutomirski пишет:


On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
 wrote:

On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:

08.03.2017 19:46, Andy Lutomirski пишет:

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

But then I am confused with the word "compat" in
your "COMPAT_MASK0_X86_UMIP_FIXUP" and
"sys_adjust_compat_mask(int op, int word, u32 mask);"

Leaving UMIP on and only disabling a fixup doesn't
sound like a compat option to me. I would expect
compat to disable it completely.

I guess that the _UMIP_FIXUP part makes it clear that emulation, not
UMIP is disabled, allowing the SIGSEGV be delivered to the user space
program.

Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
COMPAT_MASK0_X86_UMIP to disable UMIP make sense?

Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
purpose? Applications could simply use this compat mask to bypass UMIP
and gain access to the instructions it protects.


I was obviously extremely unclear.  The point of the proposed syscall
is to let programs opt out of legacy features.

I guess both "compat" and "legacy" are misleading
here. Maybe these are "x86-specific" or "hypervisor-specific",
but a mere enabling of UMIP doesn't immediately make
the use of SLDT instruction a legacy IMHO.

Sure it is. :)  Using SLDT from user mode is a legacy ability that
just happens to still work on existing CPUs and kernels.  Once UMIP
goes in, it will officially be obsolete

Yes, but the names you suggest, imply that "UMIP_FIXUP"
is legacy or compat, which I find misleading because it have
just appeared. Maybe something like "COMPAT_X86_UMIP_INSNS_EMU"?
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Fri, Mar 10, 2017 at 2:30 AM, Stas Sergeev  wrote:
> 10.03.2017 05:41, Andy Lutomirski пишет:
>
>> On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
>>  wrote:
>>>
>>> On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:

 08.03.2017 19:46, Andy Lutomirski пишет:
>>
>> No no, since I meant prot mode, this is not what I need.
>> I would never need to disable UMIP as to allow the
>> prot mode apps to do SLDT. Instead it would be good
>> to have an ability to provide a replacement for the dummy
>> emulation that is currently being proposed for kernel.
>> All is needed for this, is just to deliver a SIGSEGV.
>
> That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
> turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
> GP exit).

 But then I am confused with the word "compat" in
 your "COMPAT_MASK0_X86_UMIP_FIXUP" and
 "sys_adjust_compat_mask(int op, int word, u32 mask);"

 Leaving UMIP on and only disabling a fixup doesn't
 sound like a compat option to me. I would expect
 compat to disable it completely.
>>>
>>> I guess that the _UMIP_FIXUP part makes it clear that emulation, not
>>> UMIP is disabled, allowing the SIGSEGV be delivered to the user space
>>> program.
>>>
>>> Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
>>> COMPAT_MASK0_X86_UMIP to disable UMIP make sense?
>>>
>>> Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
>>> purpose? Applications could simply use this compat mask to bypass UMIP
>>> and gain access to the instructions it protects.
>>>
>> I was obviously extremely unclear.  The point of the proposed syscall
>> is to let programs opt out of legacy features.
>
> I guess both "compat" and "legacy" are misleading
> here. Maybe these are "x86-specific" or "hypervisor-specific",
> but a mere enabling of UMIP doesn't immediately make
> the use of SLDT instruction a legacy IMHO.

Sure it is. :)  Using SLDT from user mode is a legacy ability that
just happens to still work on existing CPUs and kernels.  Once UMIP
goes in, it will officially be obsolete -- it will just be supported
for backwards compatibility.  New code should opt out and emulate in
usermode if needed.  (And the vast, vast majority of Linux programs
don't use these instructions in the first place.)

Similarly, vsyscalls were obsolete the as soon as better alternatives
were fully supported and the kernel started making them slow, and the
fact that new static glibc programs still used them for a little while
didn't make them any less obsolete.

>
>>   I'll ponder this a bit more.
>
> So if we are to invent something new, it would be nice to
> also think up a clear terminology for it. Maybe something
> like "X86_FEATURE_xxx_MASK" or alike.

But they're misfeatures, not features.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

10.03.2017 05:41, Andy Lutomirski пишет:

On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
 wrote:

On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:

08.03.2017 19:46, Andy Lutomirski пишет:

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

But then I am confused with the word "compat" in
your "COMPAT_MASK0_X86_UMIP_FIXUP" and
"sys_adjust_compat_mask(int op, int word, u32 mask);"

Leaving UMIP on and only disabling a fixup doesn't
sound like a compat option to me. I would expect
compat to disable it completely.

I guess that the _UMIP_FIXUP part makes it clear that emulation, not
UMIP is disabled, allowing the SIGSEGV be delivered to the user space
program.

Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
COMPAT_MASK0_X86_UMIP to disable UMIP make sense?

Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
purpose? Applications could simply use this compat mask to bypass UMIP
and gain access to the instructions it protects.


I was obviously extremely unclear.  The point of the proposed syscall
is to let programs opt out of legacy features.

I guess both "compat" and "legacy" are misleading
here. Maybe these are "x86-specific" or "hypervisor-specific",
but a mere enabling of UMIP doesn't immediately make
the use of SLDT instruction a legacy IMHO.


  I'll ponder this a bit more.

So if we are to invent something new, it would be nice to
also think up a clear terminology for it. Maybe something
like "X86_FEATURE_xxx_MASK" or alike.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeev  wrote:
> 10.03.2017 05:39, Andy Lutomirski пишет:
>
>> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev  wrote:
>>>
>>> 09.03.2017 04:15, Ricardo Neri пишет:
>>>
 On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
>
> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev  wrote:
>>
>> 08.03.2017 19:06, Andy Lutomirski пишет:
>>>
>>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:

 08.03.2017 03:32, Ricardo Neri пишет:
>
> These are the instructions covered by UMIP:
> * SGDT - Store Global Descriptor Table
> * SIDT - Store Interrupt Descriptor Table
> * SLDT - Store Local Descriptor Table
> * SMSW - Store Machine Status Word
> * STR - Store Task Register
>
> This patchset initially treated tasks running in virtual-8086
>
> mode as a
>
> special case. However, I received clarification that DOSEMU[8]
>
> does not
>
> support applications that use these instructions.
>>>
>>> Can you remind me what was special about it?  It looks like you
>
> still
>>>
>>> emulate them in v8086 mode.
>>
>> Indeed, sorry, I meant prot mode here. :)
>> So I wonder what was cited to be special about v86.

 Initially my patches disabled UMIP on virtual-8086 instructions, without
 regards of protected mode (i.e., UMIP was always enabled). I didn't have
 emulation at the time. Then, I added emulation code that now covers
 protected and virtual-8086 modes. I guess it is not special anymore.
>>>
>>> But isn't SLDT just throw UD in v86?
>>> How does UMIP affect this? How does your patch affect
>>> this?
>>
>> Er, right.  Ricardo, your code may need fixing.  But don't you have a
>> test case for this?
>
> Why would you need one?
> Or do you really want to allow these instructions
> in v86 by the means of emulation? If so - this wasn't
> clearly stated in the patch description, neither it was
> properly discussed, it seems.

What I meant was: if the patches incorrectly started making these
instructions work in vm86 mode where they used to cause a vm86 exit,
then that's a bug that the selftest should have caught.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

10.03.2017 05:39, Andy Lutomirski пишет:

On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev  wrote:

09.03.2017 04:15, Ricardo Neri пишет:


On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:

On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev  wrote:

08.03.2017 19:06, Andy Lutomirski пишет:

On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:

08.03.2017 03:32, Ricardo Neri пишет:

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

This patchset initially treated tasks running in virtual-8086

mode as a

special case. However, I received clarification that DOSEMU[8]

does not

support applications that use these instructions.

Can you remind me what was special about it?  It looks like you

still

emulate them in v8086 mode.

Indeed, sorry, I meant prot mode here. :)
So I wonder what was cited to be special about v86.

Initially my patches disabled UMIP on virtual-8086 instructions, without
regards of protected mode (i.e., UMIP was always enabled). I didn't have
emulation at the time. Then, I added emulation code that now covers
protected and virtual-8086 modes. I guess it is not special anymore.

But isn't SLDT just throw UD in v86?
How does UMIP affect this? How does your patch affect
this?

Er, right.  Ricardo, your code may need fixing.  But don't you have a
test case for this?

Why would you need one?
Or do you really want to allow these instructions
in v86 by the means of emulation? If so - this wasn't
clearly stated in the patch description, neither it was
properly discussed, it seems.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
 wrote:
> On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
>> 08.03.2017 19:46, Andy Lutomirski пишет:
>> >> No no, since I meant prot mode, this is not what I need.
>> >> I would never need to disable UMIP as to allow the
>> >> prot mode apps to do SLDT. Instead it would be good
>> >> to have an ability to provide a replacement for the dummy
>> >> emulation that is currently being proposed for kernel.
>> >> All is needed for this, is just to deliver a SIGSEGV.
>> > That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
>> > turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
>> > GP exit).
>> But then I am confused with the word "compat" in
>> your "COMPAT_MASK0_X86_UMIP_FIXUP" and
>> "sys_adjust_compat_mask(int op, int word, u32 mask);"
>>
>> Leaving UMIP on and only disabling a fixup doesn't
>> sound like a compat option to me. I would expect
>> compat to disable it completely.
>
> I guess that the _UMIP_FIXUP part makes it clear that emulation, not
> UMIP is disabled, allowing the SIGSEGV be delivered to the user space
> program.
>
> Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
> COMPAT_MASK0_X86_UMIP to disable UMIP make sense?
>
> Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
> purpose? Applications could simply use this compat mask to bypass UMIP
> and gain access to the instructions it protects.
>

I was obviously extremely unclear.  The point of the proposed syscall
is to let programs opt out of legacy features.  So there would be a
bit to disable emulation of UMIP-blocked instructions (this giving the
unadulterated #GP).  There would not be a bit to disable UMIP itself.

There's also a flaw in my proposal.  Disable-vsyscall would be per-mm
and disable-umip-emulation would be per-task, so they'd need to be in
separate words to make any sense.  I'll ponder this a bit more.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev  wrote:
> 09.03.2017 04:15, Ricardo Neri пишет:
>
>> On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
>>>
>>> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev  wrote:

 08.03.2017 19:06, Andy Lutomirski пишет:
>
> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:
>>
>> 08.03.2017 03:32, Ricardo Neri пишет:
>>>
>>> These are the instructions covered by UMIP:
>>> * SGDT - Store Global Descriptor Table
>>> * SIDT - Store Interrupt Descriptor Table
>>> * SLDT - Store Local Descriptor Table
>>> * SMSW - Store Machine Status Word
>>> * STR - Store Task Register
>>>
>>> This patchset initially treated tasks running in virtual-8086
>>>
>>> mode as a
>>>
>>> special case. However, I received clarification that DOSEMU[8]
>>>
>>> does not
>>>
>>> support applications that use these instructions.
>
> Can you remind me what was special about it?  It looks like you
>>>
>>> still
>
> emulate them in v8086 mode.

 Indeed, sorry, I meant prot mode here. :)
 So I wonder what was cited to be special about v86.
>>
>> Initially my patches disabled UMIP on virtual-8086 instructions, without
>> regards of protected mode (i.e., UMIP was always enabled). I didn't have
>> emulation at the time. Then, I added emulation code that now covers
>> protected and virtual-8086 modes. I guess it is not special anymore.
>
> But isn't SLDT just throw UD in v86?
> How does UMIP affect this? How does your patch affect
> this?

Er, right.  Ricardo, your code may need fixing.  But don't you have a
test case for this?  The behavior should be the same with and without
your patches applied.  The exception is #UD, not #GP, so maybe your
code just never executes in the vm86 case.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

09.03.2017 03:46, Ricardo Neri пишет:

On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote:

08.03.2017 03:32, Ricardo Neri пишет:

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

This patchset initially treated tasks running in virtual-8086 mode as a
special case. However, I received clarification that DOSEMU[8] does not
support applications that use these instructions.

Yes, this is the case.
But at least in the past there was an attempt to
support SLDT as it is used by an ancient pharlap
DOS extender (currently unsupported by dosemu1/2).
So how difficult would it be to add an optional
possibility of delivering such SIGSEGV to userspace
so that the kernel's dummy emulation can be overridden?

I suppose a umip=noemulation kernel parameter could be added in this
case.

Why?
It doesn't need to be global: the app should be
able to change that on its own. Note that no app currently
requires this, so its just for the future, and in the
future the app can start using the new API for this,
if you provide one.



It doesn't need to be a matter of this particular
patch set, i.e. this proposal should not trigger a
v7 resend of all 21 patches. :) But it would be useful
for the future development of dosemu2.

Would dosemu2 use 32-bit processes in order to keep segmentation? If it
could use 64-bit processes, emulation is not used in this case and the
SIGSEGV is delivered to user space.

It does use the mix: 64bit process but some segments
are 32bit for DOS code.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

09.03.2017 04:15, Ricardo Neri пишет:

On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:

On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev  wrote:

08.03.2017 19:06, Andy Lutomirski пишет:

On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:

08.03.2017 03:32, Ricardo Neri пишет:

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

This patchset initially treated tasks running in virtual-8086

mode as a

special case. However, I received clarification that DOSEMU[8]

does not

support applications that use these instructions.

Can you remind me what was special about it?  It looks like you

still

emulate them in v8086 mode.

Indeed, sorry, I meant prot mode here. :)
So I wonder what was cited to be special about v86.

Initially my patches disabled UMIP on virtual-8086 instructions, without
regards of protected mode (i.e., UMIP was always enabled). I didn't have
emulation at the time. Then, I added emulation code that now covers
protected and virtual-8086 modes. I guess it is not special anymore.

But isn't SLDT just throw UD in v86?
How does UMIP affect this? How does your patch affect
this?
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

09.03.2017 04:11, Ricardo Neri пишет:

On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:

08.03.2017 19:46, Andy Lutomirski пишет:

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

But then I am confused with the word "compat" in
your "COMPAT_MASK0_X86_UMIP_FIXUP" and
"sys_adjust_compat_mask(int op, int word, u32 mask);"

Leaving UMIP on and only disabling a fixup doesn't
sound like a compat option to me. I would expect
compat to disable it completely.

I guess that the _UMIP_FIXUP part makes it clear that emulation, not
UMIP is disabled, allowing the SIGSEGV be delivered to the user space
program.

Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
COMPAT_MASK0_X86_UMIP to disable UMIP make sense?

Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
purpose? Applications could simply use this compat mask to bypass UMIP
and gain access to the instructions it protects.

I don't think someone will want to completely disable
UMIP, so why do you need such functionality?
My question was only what does "compat" mean
in "COMPAT_MASK0_X86_UMIP_FIXUP", compat with what.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:
> On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev  wrote:
> > 08.03.2017 19:06, Andy Lutomirski пишет:
> >>
> >> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:
> >>>
> >>> 08.03.2017 03:32, Ricardo Neri пишет:
> 
>  These are the instructions covered by UMIP:
>  * SGDT - Store Global Descriptor Table
>  * SIDT - Store Interrupt Descriptor Table
>  * SLDT - Store Local Descriptor Table
>  * SMSW - Store Machine Status Word
>  * STR - Store Task Register
> 
>  This patchset initially treated tasks running in virtual-8086
> mode as a
>  special case. However, I received clarification that DOSEMU[8]
> does not
>  support applications that use these instructions.
> >>
> >> Can you remind me what was special about it?  It looks like you
> still
> >> emulate them in v8086 mode.
> >
> > Indeed, sorry, I meant prot mode here. :)
> > So I wonder what was cited to be special about v86.

Initially my patches disabled UMIP on virtual-8086 instructions, without
regards of protected mode (i.e., UMIP was always enabled). I didn't have
emulation at the time. Then, I added emulation code that now covers
protected and virtual-8086 modes. I guess it is not special anymore.

Thanks and BR,
Ricardo

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:
> 08.03.2017 19:46, Andy Lutomirski пишет:
> >> No no, since I meant prot mode, this is not what I need.
> >> I would never need to disable UMIP as to allow the
> >> prot mode apps to do SLDT. Instead it would be good
> >> to have an ability to provide a replacement for the dummy
> >> emulation that is currently being proposed for kernel.
> >> All is needed for this, is just to deliver a SIGSEGV.
> > That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
> > turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
> > GP exit).
> But then I am confused with the word "compat" in
> your "COMPAT_MASK0_X86_UMIP_FIXUP" and
> "sys_adjust_compat_mask(int op, int word, u32 mask);"
> 
> Leaving UMIP on and only disabling a fixup doesn't
> sound like a compat option to me. I would expect
> compat to disable it completely.

I guess that the _UMIP_FIXUP part makes it clear that emulation, not
UMIP is disabled, allowing the SIGSEGV be delivered to the user space
program.

Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
COMPAT_MASK0_X86_UMIP to disable UMIP make sense?

Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
purpose? Applications could simply use this compat mask to bypass UMIP
and gain access to the instructions it protects.

Thanks and BR,
Ricardo

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Ricardo Neri]

On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote:
> 08.03.2017 03:32, Ricardo Neri пишет:
> > These are the instructions covered by UMIP:
> > * SGDT - Store Global Descriptor Table
> > * SIDT - Store Interrupt Descriptor Table
> > * SLDT - Store Local Descriptor Table
> > * SMSW - Store Machine Status Word
> > * STR - Store Task Register
> >
> > This patchset initially treated tasks running in virtual-8086 mode as a
> > special case. However, I received clarification that DOSEMU[8] does not
> > support applications that use these instructions.
> Yes, this is the case.
> But at least in the past there was an attempt to
> support SLDT as it is used by an ancient pharlap
> DOS extender (currently unsupported by dosemu1/2).
> So how difficult would it be to add an optional
> possibility of delivering such SIGSEGV to userspace
> so that the kernel's dummy emulation can be overridden?

I suppose a umip=noemulation kernel parameter could be added in this
case.

> It doesn't need to be a matter of this particular
> patch set, i.e. this proposal should not trigger a
> v7 resend of all 21 patches. :) But it would be useful
> for the future development of dosemu2.

Would dosemu2 use 32-bit processes in order to keep segmentation? If it
could use 64-bit processes, emulation is not used in this case and the
SIGSEGV is delivered to user space.

Thanks and BR,
Ricardo


--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

08.03.2017 19:06, Andy Lutomirski пишет:

On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:

08.03.2017 03:32, Ricardo Neri пишет:

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

This patchset initially treated tasks running in virtual-8086 mode as a
special case. However, I received clarification that DOSEMU[8] does not
support applications that use these instructions.

Can you remind me what was special about it?  It looks like you still
emulate them in v8086 mode.

Indeed, sorry, I meant prot mode here. :)
So I wonder what was cited to be special about v86.


Yes, this is the case.
But at least in the past there was an attempt to
support SLDT as it is used by an ancient pharlap
DOS extender (currently unsupported by dosemu1/2).
So how difficult would it be to add an optional
possibility of delivering such SIGSEGV to userspace
so that the kernel's dummy emulation can be overridden?
It doesn't need to be a matter of this particular
patch set, i.e. this proposal should not trigger a
v7 resend of all 21 patches. :) But it would be useful
for the future development of dosemu2.

What I'd actually like to see is a totally separate patchset that adds
an inheritable (but reset on exec) per-task mask of legacy
compatibility features to disable.  Maybe:

sys_adjust_compat_mask(int op, int word, u32 mask);

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev  wrote:
> 08.03.2017 19:06, Andy Lutomirski пишет:
>>
>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:
>>>
>>> 08.03.2017 03:32, Ricardo Neri пишет:

 These are the instructions covered by UMIP:
 * SGDT - Store Global Descriptor Table
 * SIDT - Store Interrupt Descriptor Table
 * SLDT - Store Local Descriptor Table
 * SMSW - Store Machine Status Word
 * STR - Store Task Register

 This patchset initially treated tasks running in virtual-8086 mode as a
 special case. However, I received clarification that DOSEMU[8] does not
 support applications that use these instructions.
>>
>> Can you remind me what was special about it?  It looks like you still
>> emulate them in v8086 mode.
>
> Indeed, sorry, I meant prot mode here. :)
> So I wonder what was cited to be special about v86.

Not sure.  Ricardo?

>
>>> Yes, this is the case.
>>> But at least in the past there was an attempt to
>>> support SLDT as it is used by an ancient pharlap
>>> DOS extender (currently unsupported by dosemu1/2).
>>> So how difficult would it be to add an optional
>>> possibility of delivering such SIGSEGV to userspace
>>> so that the kernel's dummy emulation can be overridden?
>>> It doesn't need to be a matter of this particular
>>> patch set, i.e. this proposal should not trigger a
>>> v7 resend of all 21 patches. :) But it would be useful
>>> for the future development of dosemu2.
>>
>> What I'd actually like to see is a totally separate patchset that adds
>> an inheritable (but reset on exec) per-task mask of legacy
>> compatibility features to disable.  Maybe:
>>
>> sys_adjust_compat_mask(int op, int word, u32 mask);
>
> No no, since I meant prot mode, this is not what I need.
> I would never need to disable UMIP as to allow the
> prot mode apps to do SLDT. Instead it would be good
> to have an ability to provide a replacement for the dummy
> emulation that is currently being proposed for kernel.
> All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

08.03.2017 19:46, Andy Lutomirski пишет:

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

But then I am confused with the word "compat" in
your "COMPAT_MASK0_X86_UMIP_FIXUP" and
"sys_adjust_compat_mask(int op, int word, u32 mask);"

Leaving UMIP on and only disabling a fixup doesn't
sound like a compat option to me. I would expect
compat to disable it completely.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev  wrote:
> 08.03.2017 03:32, Ricardo Neri пишет:
>>
>> These are the instructions covered by UMIP:
>> * SGDT - Store Global Descriptor Table
>> * SIDT - Store Interrupt Descriptor Table
>> * SLDT - Store Local Descriptor Table
>> * SMSW - Store Machine Status Word
>> * STR - Store Task Register
>>
>> This patchset initially treated tasks running in virtual-8086 mode as a
>> special case. However, I received clarification that DOSEMU[8] does not
>> support applications that use these instructions.

Can you remind me what was special about it?  It looks like you still
emulate them in v8086 mode.

>
> Yes, this is the case.
> But at least in the past there was an attempt to
> support SLDT as it is used by an ancient pharlap
> DOS extender (currently unsupported by dosemu1/2).
> So how difficult would it be to add an optional
> possibility of delivering such SIGSEGV to userspace
> so that the kernel's dummy emulation can be overridden?
> It doesn't need to be a matter of this particular
> patch set, i.e. this proposal should not trigger a
> v7 resend of all 21 patches. :) But it would be useful
> for the future development of dosemu2.

What I'd actually like to see is a totally separate patchset that adds
an inheritable (but reset on exec) per-task mask of legacy
compatibility features to disable.  Maybe:

sys_adjust_compat_mask(int op, int word, u32 mask);

op could indicate that we want to so SET, OR, AND, or READ.  word
would be 0 for now.  It could be a prctl, too.

Things in the mask could include:

COMPAT_MASK0_X86_64_VSYSCALL [1]
COMPAT_MASK0_X86_UMIP_FIXUP

I'm sure I could think of more along these lines.

Then DOSEMU (and future WINE versions, too) could just mask off
X86_UMIP_FIXUP and do their own emulation

[1] For those of you thinking about this and realizing that VSYSCALL
readability is inherently global and not per-task, I know how to fix
that for essentially no cost :)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Andy Lutomirski]

On Tue, Mar 7, 2017 at 4:32 PM, Ricardo Neri
 wrote:
> This is v6 of this series. The five previous submissions can be found
> here [1], here [2], here[3], here[4], and here[5]. This version addresses
> the comments received in v4 plus improvements of the handling of emulation
> in 64-bit builds. Please see details in the change log.
>

Hi Ingo and Thomas-

I think this series is in good enough shape that you should consider
making a topic branch (x86/umip?) for it so that it can soak in -next
and further development can be done incrementally.  In the unlikely
event that a major problem shows up, you could skip the pull request
to Linus for a cycle.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html