[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP



On 06/12/16 11:44, Jan Beulich wrote:
> There are three noteworthy drawbacks:
> 1) The intercepts we need to enable here are CPL-independent, i.e. we
>    now have to emulate certain instructions for ring 0.
> 2) On VMX there's no intercept for SMSW, so the emulation isn't really
>    complete there.
> 3) The CR4 write intercept on SVM is lower priority than all exception
>    checks, so we need to intercept #GP.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

I have had a brief look over the patch, but not reviewed it in detail yet.

First of all, would you mind pulling the 64bit segment implementation
into a separate patch?  They are somewhat orthogonal to UMIP, and the
code looks fine.  They will also let me finish my comprehensive user and
system segment emulation handling XTF tests which I developed during the
XSA-191 work.

As for UMIP itself, there are a number of issues which we should
consider here.

First, this adds quite a lot of emulation and extra handling in security
sensitive areas.  That isn't a problem per say, but given concerns with
emulation in general (and indeed the efforts to remove all emulation
from some usecases), making it unilaterally enabled is a problem.

As such, I think emulated-UMIP is an option which the user must
explicitly opt-in to.  The easiest option might be to defer adding
emulated-UMIP until I have split the default and max featureset options
in the CPUID policy ABI (which is the task I am currently working ok).

However, it would also require only enabling the SVM GP intercept in the
hvm_update_guest_vendor() path (which should be renamed to something
slightly more generic like hvm_cpuid_policy_updated()).


Given the complexity of the interactions, I think we should have a
dedicated XTF test for UMIP behaviour, similar to the CPUID faulting
one.  I can see about implementing that if you don't want to.

> ---
> The tool stack change could be left out - it updates a table which is
> rather out of date anyway.
> ---
> This once again points out that handle_mmio() is rather badly named, as
> it's about more than just MMIO. Since we have hvm_emulate_one()
> already, I am, however, lacking an idea for a good alternative name.

As am I.  A number of its current uses are not for MMIO at all, and
would ideally go with some further restriction of emulated instruction.

~Andrew

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.