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

Groups > linux.kernel > #1594751 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 09/21] x86/insn-eval: Add functions to get default operand and address sizes Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 03/21] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0 Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 08/21] x86/insn-eval: Add utility function to get segment descriptor base address Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 15/21] x86/mm: Relocate page fault error codes to traps.h Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
      Re: [v6 PATCH 15/21] x86/mm: Relocate page fault error codes to traps.h Andy Lutomirski <luto@amacapital.net> - 2017-03-08 17:10 +0100
    [v6 PATCH 11/21] insn/eval: Incorporate segment base in address computation Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 16/21] x86/cpufeature: Add User-Mode Instruction Prevention definitions Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 21/21] selftests/x86: Add tests for User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
      Re: [v6 PATCH 21/21] selftests/x86: Add tests for User-Mode  Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-08 17:30 +0100
        Re: [v6 PATCH 21/21] selftests/x86: Add tests for User-Mode  Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 00:40 +0100
    [v6 PATCH 01/21] x86/mpx: Use signed variables to compute effective addresses Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:40 +0100
    [v6 PATCH 20/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 13/21] x86/insn-eval: Add support to resolve 16-bit addressing encodings Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 17/21] x86: Add emulation code for UMIP instructions Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 05/21] x86/insn-eval: Add utility functions to get register offsets Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 12/21] x86/insn: Support both signed 32-bit and 64-bit effective addresses Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 07/21] x86/insn-eval: Add utility function to get segment descriptor Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 18/21] x86/umip: Force a page fault when unable to copy emulated result to user Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 14/21] x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 01:50 +0100
    [v6 PATCH 06/21] x86/insn-eval: Add utility functions to get segment selector Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 02:00 +0100
    [v6 PATCH 02/21] x86/mpx: Do not use SIB index if index points to R/ESP Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 02:00 +0100
    [v6 PATCH 19/21] x86/traps: Fixup general protection faults caused by UMIP Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 02:00 +0100
      Re: [v6 PATCH 19/21] x86/traps: Fixup general protection faults  caused by UMIP Andy Lutomirski <luto@amacapital.net> - 2017-03-08 17:00 +0100
    [v6 PATCH 10/21] x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 02:10 +0100
    [v6 PATCH 04/21] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-08 04:50 +0100
    Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-08 15:30 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-08 18:00 +0100
        Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-09 02:20 +0100
          Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-09 23:10 +0100
          Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@kernel.org> - 2017-03-10 03:50 +0100
            Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-10 22:00 +0100
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-10 22:10 +0100
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-10 22:40 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-08 18:20 +0100
        Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-09 02:20 +0100
          Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-09 23:20 +0100
            Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-10 03:50 +0100
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-10 12:40 +0100
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-10 15:20 +0100
                  Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 02:30 +0100
                Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 01:10 +0100
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 01:00 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-08 23:30 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-08 23:50 +0100
      Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-09 02:50 +0100
        Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-10 02:30 +0100
          Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 00:50 +0100
            Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Stas Sergeev <stsp@list.ru> - 2017-03-11 01:00 +0100
              Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-03-11 01:20 +0100
    Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention Andy Lutomirski <luto@amacapital.net> - 2017-03-08 17:20 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#1598220

On Fri, 2017-03-10 at 06:17 -0800, Andy Lutomirski wrote:
> On Fri, Mar 10, 2017 at 3:33 AM, Stas Sergeev <stsp@list.ru> wrote:
> > 10.03.2017 05:39, Andy Lutomirski пишет:
> >
> >> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev <stsp@list.ru> 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 <stsp@list.ru> wrote:
> >>>>>>
> >>>>>> 08.03.2017 19:06, Andy Lutomirski пишет:
> >>>>>>>
> >>>>>>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> 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&friends 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.

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

#1598192

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 <stsp@list.ru> 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 <stsp@list.ru> wrote:
> >>>>> 08.03.2017 19:06, Andy Lutomirski пишет:
> >>>>>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> 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&friends 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

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

#1598188

On Thu, 2017-03-09 at 18:39 -0800, Andy Lutomirski wrote:
> On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev <stsp@list.ru> 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 <stsp@list.ru> wrote:
> >>>>
> >>>> 08.03.2017 19:06, Andy Lutomirski пишет:
> >>>>>
> >>>>> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> 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&friends 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

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

#1595558

08.03.2017 19:06, Andy Lutomirski пишет:
> On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> 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.

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

#1595567

On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <stsp@list.ru> 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

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

#1595630

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

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

#1596538

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.

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

#1598185

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

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

#1598190

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.

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

#1598194

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

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

#1595327

On Tue, Mar 7, 2017 at 4:32 PM, Ricardo Neri
<ricardo.neri-calderon@linux.intel.com> 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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web