Re: [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 01/07/15 17:13, Stefano Stabellini wrote:
> On Wed, 1 Jul 2015, Andrew Cooper wrote:
>> On 01/07/15 16:51, Boris Ostrovsky wrote:
>>> On 07/01/2015 11:46 AM, Andrew Cooper wrote:
>>>> On 01/07/15 15:46, Roger Pau Monne wrote:
>>>>> Introduce a new DOMCTL flag that can be used to disable device
>>>>> emulation
>>>>> inside of Xen for HVM guests. The following emulated devices are
>>>>> disabled
>>>>> when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic,
>>>>> lapic,
>>>>> pic and pmu. Also all the MMIO handlers are disabled.
>>>>>
>>>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>>>> Cc: Jan Beulich <jbeulich@suse.com>
>>>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>>>>> Cc: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
>>>>> Cc: Jun Nakajima <jun.nakajima@intel.com>
>>>>> Cc: Eddie Dong <eddie.dong@intel.com>
>>>>> Cc: Kevin Tian <kevin.tian@intel.com>
>>>> I would be hesitant to have a blanket change like this.
>>>>
>>>> Consider APICV/AVIC.  For performance reasons, we absolutely want HVM
>>>> and PVH to make use of them, as they are substantially more efficient
>>>> using hardware support than evening using plain evtchn hypercalls.
>>>>
>>>> However, the flipside is that we must provide an LAPIC emulation to
>>>> cover the bits which hardware cannot virtualise.
>>>>
>>>> As a random idea, how about having a new hypercall or hvmparam which
>>>> provides a bitmap of permitted emulators?  This would allow far finer
>>>> grain control over what is and isn't available to a domain.
>>> I think we also need to decide on which subsets of emulators we are
>>> going to support, otherwise test matrix will become pretty big. For
>>> example, initially we may want to allow all (for what we now call HVM)
>>> or none (PVH).
>> Right, but that can currently be enforced with an "if ( arg != 0 && arg
>> != ~0 ) return -EOPNOTSUPP;" in the hypercall handler for now.
>>
>> It still leaves us with the ability to add in LAPIC emulation in the
>> future by changing the auditing.  A blanket "no emulation" boolean is
>> very much harder to relax in the future.
> APICV is a bit of a special case, because it is partially virtualized in
> hardware.

Not in the slightest.  It is *exactly* the same as existing hardware
virt.  Hardware does most of the work, but occasionally needs to break
into Xen to mange thing.  The difference is that we don't call some of
the existing vmexits "emulating an x86 cpu", despite this being what is
actually happening.

> But in general, considering that the whole purpose of PVH as DomU is
> security

Says who?  An entirely reasonable alternate opinion is "HVM without the
emulation overhead".

> , as a Xen user, I would not want any emulators running with PVH
> guests. Otherwise I might as well run PV on HVM.

That is fine from a security point of view, but is not shared by most
users Xen.

Most users of Xen want to squeeze every ounce of performance out of the
hardware they paid $$$ for, and won't mind exposing an LAPIC
implementation to a PVH guest, seeing as the same implementation is
available to windows or existing PVHVM guests.

(when eventually supported), offering host administrators a choice
between more security or more performance is perfectly ok, but designing
PVH to be secure at the deliberate detriment of performance is unacceptable.

> Being able to enable/disable specific emulators sounds more future
> proof, but in practice it is likely to lead to many broken non default
> configs.

Not if Xen has a sensible audit for combinations (which is precisely
what I suggested).

~Andrew

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