10.03.2017 05:41, Andy Lutomirski пишет:
On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri ricardo.neri-calderon@linux.intel.com 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.