Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Sep 07, 2017 at 11:49:00AM +0100, George Dunlap wrote:
> On 08/31/2017 12:25 PM, Roger Pau Monne wrote:
> > On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
> >> +### x86/PV-on-HVM
> > 
> > Do we really consider this a guest type? From both Xen and the
> > toolstack PoV this is just a HVM guest. What's more, I'm not really
> > sure xl/libxl has the right options to create a HVM guest _without_
> > exposing any PV interfaces.
> > 
> > Ie: can a HMV guest without PV timers and PV event channels
> > actually be created? Or even without having the MSR to initialize the
> > hypercall page.
> 
> This document has its sources in the "feature support" page.  "PVHVM" is
> a collective term that was used at the time for exposing a number of
> individual interfaces to the guest; I think a lot of that work happened
> around the 4.2-4.3 timeframe.  And *one* of the goals, if I understand
> correctly, is to allow the automatic generation of such a table from the
> Xen sources.
> 
> It may be that we don't need to mention this as a separate feature
> anymore; or it may be that we can categorize this differently somehow --
> I'm open to suggestions here.

We marketed this as PVHVM, but I think this term applies to OSes
rather than Xen guest types.

From a Xen PoV, they are just HVM OSes.  Some of them make use of more
PV interfaces than others, but all HVM guests have the same set of
interfaces available to them, and thus the same surface of attack.

I don't think it makes sense to list PVHVM as a guest type in the list
of supported features.

> >> +### x86/PVH dom0
> >               ^ v2
> >> +
> >> +    Status: Experimental
> > 
> > The status of this is just "not finished". We need at least the PCI
> > emulation series for having a half-functional PVHv2 Dom0.
> 
> From the definition of 'Experimental':
> 
>     Functional completeness: No
>     Functional stability: Here be dragons
>     Interface stability: Not stable
>     Security supported: No
> 
> "Not finished" -> Functional completeness: No -> Experimental.
> 
> If there's no way of doing anything with dom0 at all we should probably
> just remove it from the list.

Right now it should be removed according to the logic above.

> >> +### ACPI guest
> >> +
> >> +    Status, ARM: Preview
> >        Status: Supported
> > 
> > HVM guests have been using ACPI for a long time on x86.
> 
> You mean 'Status, x86 HVM: Supported', I take it?

Right.

> >> +### Online resize of virtual disks
> >> +
> >> +    Status: Supported
> > 
> > That pretty much depends on where you are actually storing your disks
> > I guess. I'm not sure we want to make such compromises.
> 
> What do you mean?

I'm not sure online resizing is something that needs spelling out
separately, it's part of how the block protocol works, just like
indirect descriptors or persistent grants (which are also not listed
here, and I think that's fine).

> >> +### x86/HVM iPXE
> >> +
> >> +    Status: Supported, with caveats
> >> +
> >> +Booting a guest via PXE.
> >> +PXE inherently places full trust of the guest in the network,
> >> +and so should only be used
> >> +when the guest network is under the same administrative control
> >> +as the guest itself.
> > 
> > Hm, not sure why this needs to be spelled out, it's just like running
> > any bootloader/firmware inside a HVM guest, which I'm quite sure we
> > are not going to list here.
> > 
> > Ie: I don't see us listing OVMF, SeaBIOS or ROMBIOS, simply because
> > they run inside the guest, so if they are able to cause security
> > issues, anything else is also capable of causing them.
> 
> Well iPXE is a feature, so we have to say something about it; and there
> was a long discussion at the Summit about whether we should list iPXE as
> "security supported", because *by design* it just runs random code that
> someone sends it over the network.  But if we say it's not supported, it
> makes it sound like we think you shouldn't use it.
> 
> Above was the agreed-upon compromise: to say it was supported but warn
> people what "supported" means.

Hm, I'm still not sure this should be explicitly listed here.

Running random code inside of a guest is not a problem from Xen's PoV,
and we would never issue a XSA, unless such code is able to break
outside of the guest, in which case it doesn't matter whether the code
has been randomly fetched from the network.

IMHO iPXE is just like any other firmware that Xen supports, such as
OVMF/SeaBIOS/ROMBIOS, and I don't see them listed here. I'm not sure
in which way iPXE is special from the other ones that requires such an
entry in the support document.

> >> +### ARM/SMMU
> >> +
> >> +    Status: Supported, with caveats
> >> +
> >> +Only ARM SMMU hardware is supported; non-ARM SMMU hardware is not 
> >> supported.
> > 
> > I'm not sure of the purpose of this sentence, it's quite clear that
> > the SMMU is only supported if available. Also, I'm not sure this
> > should be spelled out in this document, x86 doesn't have a VT-d or SVM
> > section.
> 
> This sentence means, "An SMMU designed by ARM", as opposed to an SMMU
> (or SMMU-like thing) designed by someone other than ARM.  (And yes, I
> understand that such things existed before the ARM SMMU came out.)
> 
> I think people running ARM systems will understand what the sentence means.

Oh, thanks. I didn't know there was such a difference in the ARM
world.

Thanks, Roger.

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