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 <jbeul...@suse.com>
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@lists.xen.org https://lists.xen.org/xen-devel
