On Fri, Mar 10, 2017 at 2:30 AM, Stas Sergeev <stsp@xxxxxxx> wrote:Yes, but the names you suggest, imply that "UMIP_FIXUP"
10.03.2017 05:41, Andy Lutomirski ÐÐÑÐÑ:Sure it is. :) Using SLDT from user mode is a legacy ability that
On Wed, Mar 8, 2017 at 5:11 PM, Ricardo NeriI guess both "compat" and "legacy" are misleading
On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:I was obviously extremely unclear. The point of the proposed syscall
08.03.2017 19:46, Andy Lutomirski ÐÐÑÐÑ:I guess that the _UMIP_FIXUP part makes it clear that emulation, not
But then I am confused with the word "compat" inNo no, since I meant prot mode, this is not what I need.That's what I meant. Turning off FIXUP_UMIP would leave UMIP on but
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.
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
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.
UMIP is disabled, allowing the SIGSEGV be delivered to the user space
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.
is to let programs opt out of legacy features.
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.
just happens to still work on existing CPUs and kernels. Once UMIP
goes in, it will officially be obsolete