Re: [PATCH 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit

["Jan Beulich" <JBeulich@suse.com>]

>>> On 06.06.17 at 15:00, <apop@bitdefender.com> wrote:
> On Mon, May 29, 2017 at 08:38:33AM -0600, Jan Beulich wrote:
>> >>> On 18.05.17 at 17:07, <apop@bitdefender.com> wrote:
>> > +
>> > +    if ( !cpu_has_vmx )
>> > +        return -EOPNOTSUPP;
>> 
>> Is this enough? Wouldn't it be better to signal the caller whenever
>> hardware (or even software) isn't going to honor the request?
> 
> Well, the caller checks the return value.  The libxc function
> xc_altp2m_set_suppress_ve for instance will return a negative in this
> case.

The question wasn't what the caller does but whether checking just
cpu_has_vmx is enough. What if you're running on a machine with
VMX but no #VE support?

>> And then there are two general questions: Without a libxc layer
>> function, how is one supposed to use this new sub-op? Is it
>> really intended to permit a guest to call this for itself?
>  
> Well, the sub-op could be used from a Linux kernel module if libxc is
> not available if struct xen_hvm_altp2m_op and struct
> xen_hvm_altp2m_set_suppress_ve are defined.
> 
> Our use case, though, involves either Dom0 or a "privileged" DomU
> altering the suppress #VE bit for the target guest.

This doesn't really answer the question: What are the security
implications if a guest can invoke this on itself?

(FTR I think my first question was kind of pointless, as patch 3
looks like it does introduce a libxc function; I simply didn't realize
that back then, because I'd generally have expected the
consumer of the hypercall to be introduce together with the
producer.)

Jan


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