[PATCH] x86/pv: Prohibit attempts to initialise a vcpu with EFLAGS.{NT, VM} set

[PATCH] x86/pv: Prohibit attempts to initialise a vcpu with EFLAGS.{NT, VM} set

[Andrew Cooper]

Luckily, this isn't a security issue, because the fix for XSA-202 (c/s
0e47f92b072) took a proactive aproach and clobbered these flags on the
exit-to-guest path.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
---
 xen/arch/x86/domain.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index dbddc53..ced1d2e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -765,7 +765,8 @@ int arch_set_info_guest(
                  !is_canonical_address(c.nat->gs_base_user) ||
                  !is_canonical_address(c.nat->event_callback_eip) ||
                  !is_canonical_address(c.nat->syscall_callback_eip) ||
-                 !is_canonical_address(c.nat->failsafe_callback_eip) )
+                 !is_canonical_address(c.nat->failsafe_callback_eip) ||
+                 (c.nat->user_regs.rflags & (X86_EFLAGS_NT|X86_EFLAGS_VM)) )
                 return -EINVAL;
 
             fixup_guest_stack_selector(d, c.nat->user_regs.ss);
@@ -784,6 +785,9 @@ int arch_set_info_guest(
         }
         else
         {
+            if ( c.nat->user_regs.eflags & (X86_EFLAGS_NT|X86_EFLAGS_VM) )
+                return -EINVAL;
+
             fixup_guest_stack_selector(d, c.cmp->user_regs.ss);
             fixup_guest_stack_selector(d, c.cmp->kernel_ss);
             fixup_guest_code_selector(d, c.cmp->user_regs.cs);
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH] x86/pv: Prohibit attempts to initialise a vcpu with EFLAGS.{NT, VM} set

[Jan Beulich]

>>> On 31.08.17 at 19:07, <andrew.cooper3@citrix.com> wrote:
> Luckily, this isn't a security issue, because the fix for XSA-202 (c/s
> 0e47f92b072) took a proactive aproach and clobbered these flags on the
> exit-to-guest path.

Which makes me wonder whether ...

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -765,7 +765,8 @@ int arch_set_info_guest(
>                   !is_canonical_address(c.nat->gs_base_user) ||
>                   !is_canonical_address(c.nat->event_callback_eip) ||
>                   !is_canonical_address(c.nat->syscall_callback_eip) ||
> -                 !is_canonical_address(c.nat->failsafe_callback_eip) )
> +                 !is_canonical_address(c.nat->failsafe_callback_eip) ||
> +                 (c.nat->user_regs.rflags & (X86_EFLAGS_NT|X86_EFLAGS_VM)) )
>                  return -EINVAL;

... it is appropriate to fail the hypercall here, instead of simply
clearing the bogus flags, just like we also force IF on instead of
failing the operation.

> @@ -784,6 +785,9 @@ int arch_set_info_guest(
>          }
>          else
>          {
> +            if ( c.nat->user_regs.eflags & (X86_EFLAGS_NT|X86_EFLAGS_VM) )
> +                return -EINVAL;

Don't you mean c.cmp here? In fact I could see failing the request to
really be the right thing for compat guests (at least for VM), while
ignoring the request to set either flag for native guests (as being
meaningless in 64-bit mode).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel