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

[Stas Sergeev]

10.03.2017 05:41, Andy Lutomirski ÐÐÑÐÑ:
> 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.
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.