Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
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
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&friends 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
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
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&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. --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
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
