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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.08.17 at 19:07, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel