x86: Secure eflags when securing contexts
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 28 Jul 2016 20:42:21 +0000 (16:42 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Fri, 29 Jul 2016 21:43:08 +0000 (17:43 -0400)
We had been making sure interrupts was on, but we weren't enforcing some of
the other flags.  I don't know if this is all of them, but it's the list of
ones that sounded dangerous from the SDM.

The IOPL one was probably a security hole.  A process could have asked the
kernel to pop a HWTF that had IOPL set to 3, and then started mucking with
devices.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/arch/x86/process64.c

index e141873..dd31ddb 100644 (file)
@@ -261,7 +261,13 @@ static void proc_secure_hwtf(struct hw_trapframe *tf)
         * Requestor Privilege Level (RPL); 3 means user mode. */
        tf->tf_ss = GD_UD | 3;
        tf->tf_cs = GD_UT | 3;
+       /* Always 1: interrupts */
        tf->tf_rflags |= FL_IF;
+       /* Always 0: IOPL must be set to 0.  VM (virtual 8086) probably doesn't
+        * matter - SDM says it can't get modified via iret anyways.  VIF and VIP
+        * are also virtual-8086 mode stuff.  Supposedly NT is settable by
+        * userspace, but there's no good reason for it.  Rather be paranoid. */
+       tf->tf_rflags &= ~(FL_IOPL_MASK | FL_VM | FL_NT | FL_VIF | FL_VIP);
        x86_hwtf_clear_partial(tf);
 }