On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri <ricardo.neri-calderon@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
