Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1610166 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-28 01:50 +0200
    Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-28 11:50 +0200
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-29 06:40 +0200
        Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-29 23:20 +0200
          Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-30 07:20 +0200
            Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-30 12:20 +0200
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-31 03:40 +0200
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Alexandre Julliard <julliard@winehq.org> - 2017-03-31 17:00 +0200
                  Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-31 23:50 +0200
                    Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@kernel.org> - 2017-04-01 04:20 +0200
                  Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-04-04 04:10 +0200
                    Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Alexandre Julliard <julliard@winehq.org> - 2017-04-04 08:10 +0200
            Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-04-01 15:10 +0200
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention "H. Peter Anvin" <hpa@zytor.com> - 2017-04-01 20:10 +0200
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-04-02 18:00 +0200
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-04-04 12:10 +0200
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-04-04 04:10 +0200
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-04-04 10:10 +0200

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

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

[toc] | [next] | [standalone]

#1610494

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

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? Or should
the UMIP be enabled under kvm by hands?

>> 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.
But at least dosemu implements it, so probably it is needed.
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. :) So, if this can be
an option, I can do the tests to estimate its usage.

[toc] | [prev] | [next] | [standalone]

#1611551

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

[toc] | [prev] | [next] | [standalone]

#1612363

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.

[toc] | [prev] | [next] | [standalone]

#1612563

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.

[toc] | [prev] | [next] | [standalone]

#1612874

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.

[toc] | [prev] | [next] | [standalone]

#1613572

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

[toc] | [prev] | [next] | [standalone]

#1614087

Ricardo Neri <ricardo.neri-calderon@linux.intel.com> 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
julliard@winehq.org

[toc] | [prev] | [next] | [standalone]

#1614302

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?

[toc] | [prev] | [next] | [standalone]

#1614364

On Fri, Mar 31, 2017 at 2:26 PM, Stas Sergeev <stsp@list.ru> 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

[toc] | [prev] | [next] | [standalone]

#1615653

On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote:
> Ricardo Neri <ricardo.neri-calderon@linux.intel.com> 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

[toc] | [prev] | [next] | [standalone]

#1615718

Ricardo Neri <ricardo.neri-calderon@linux.intel.com> writes:

> On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote:
>> Ricardo Neri <ricardo.neri-calderon@linux.intel.com> 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
julliard@winehq.org

[toc] | [prev] | [next] | [standalone]

#1614503

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

[toc] | [prev] | [next] | [standalone]

#1614575

<x86@kernel.org>,linux-msdos@vger.kernel.org,wine-devel@winehq.org
From: hpa@zytor.com
Message-ID: <3FD12652-AA83-4D73-9914-BBA089E58FFA@zytor.com>

On April 1, 2017 6:08:43 AM PDT, Stas Sergeev <stsp@list.ru> 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.

[toc] | [prev] | [next] | [standalone]

#1614761

On Sat, Apr 1, 2017 at 10:49 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> <x86@kernel.org>,linux-msdos@vger.kernel.org,wine-devel@winehq.org
> From: hpa@zytor.com
> Message-ID: <3FD12652-AA83-4D73-9914-BBA089E58FFA@zytor.com>
>
> On April 1, 2017 6:08:43 AM PDT, Stas Sergeev <stsp@list.ru> 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.

I think we should emulate all the instructions (as documented in the
SDM, so things that #UD in v86 mode still do so) rather than trying to
be clever.  If we're clever and we get it wrong, we might discover
that something started depending on our cleverness in the mean time.

--Andy

[toc] | [prev] | [next] | [standalone]

#1615857

01.04.2017 20:49, H. Peter Anvin пишет:
> <x86@kernel.org>,linux-msdos@vger.kernel.org,wine-devel@winehq.org
> From: hpa@zytor.com
> Message-ID: <3FD12652-AA83-4D73-9914-BBA089E58FFA@zytor.com>
>
> On April 1, 2017 6:08:43 AM PDT, Stas Sergeev <stsp@list.ru> 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.
Perhaps sgdt in v86 is used (very rare) for the same purpose then.

[toc] | [prev] | [next] | [standalone]

#1615651

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. Perhaps sidt? 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?

Thanks and BR,
Ricardo

[toc] | [prev] | [next] | [standalone]

#1615769

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web