Re: [Xen-devel] [PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 20 Jan 2016, Andrew Cooper wrote:
> On 20/01/16 14:29, Stefano Stabellini wrote:
> > On Wed, 20 Jan 2016, Andrew Cooper wrote:
> >> On 20/01/16 10:36, Xiao Guangrong wrote:
> >>> Hi,
> >>>
> >>> On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
> >>>
> >>>> CCing QEMU vNVDIMM maintainer: Xiao Guangrong
> >>>>
> >>>>> Conceptually, an NVDIMM is just like a fast SSD which is linearly
> >>>>> mapped
> >>>>> into memory.  I am still on the dom0 side of this fence.
> >>>>>
> >>>>> The real question is whether it is possible to take an NVDIMM, split it
> >>>>> in half, give each half to two different guests (with appropriate NFIT
> >>>>> tables) and that be sufficient for the guests to just work.
> >>>>>
> >>>> Yes, one NVDIMM device can be split into multiple parts and assigned
> >>>> to different guests, and QEMU is responsible to maintain virtual NFIT
> >>>> tables for each part.
> >>>>
> >>>>> Either way, it needs to be a toolstack policy decision as to how to
> >>>>> split the resource.
> >>> Currently, we are using NVDIMM as a block device and a DAX-based
> >>> filesystem
> >>> is created upon it in Linux so that file-related accesses directly reach
> >>> the NVDIMM device.
> >>>
> >>> In KVM, If the NVDIMM device need to be shared by different VMs, we can
> >>> create multiple files on the DAX-based filesystem and assign the file to
> >>> each VMs. In the future, we can enable namespace (partition-like) for
> >>> PMEM
> >>> memory and assign the namespace to each VMs (current Linux driver uses
> >>> the
> >>> whole PMEM as a single namespace).
> >>>
> >>> I think it is not a easy work to let Xen hypervisor recognize NVDIMM
> >>> device
> >>> and manager NVDIMM resource.
> >>>
> >>> Thanks!
> >>>
> >> The more I see about this, the more sure I am that we want to keep it as
> >> a block device managed by dom0.
> >>
> >> In the case of the DAX-based filesystem, I presume files are not
> >> necessarily contiguous.  I also presume that this is worked around by
> >> permuting the mapping of the virtual NVDIMM such that the it appears as
> >> a contiguous block of addresses to the guest?
> >>
> >> Today in Xen, Qemu already has the ability to create mappings in the
> >> guest's address space, e.g. to map PCI device BARs.  I don't see a
> >> conceptual difference here, although the security/permission model
> >> certainly is more complicated.
> > I imagine that mmap'ing  these /dev/pmemXX devices require root
> > privileges, does it not?
> 
> I presume it does, although mmap()ing a file on a DAX filesystem will
> work in the standard POSIX way.
> 
> Neither of these are sufficient however.  That gets Qemu a mapping of
> the NVDIMM, not the guest.  Something, one way or another, has to turn
> this into appropriate add-to-phymap hypercalls.
> 
> >
> > I wouldn't encourage the introduction of anything else that requires
> > root privileges in QEMU. With QEMU running as non-root by default in
> > 4.7, the feature will not be available unless users explicitly ask to
> > run QEMU as root (which they shouldn't really).
> 
> This isn't how design works.
> 
> First, design a feature in an architecturally correct way, and then
> design an security policy to fit.
>
> We should not stunt design based on an existing implementation.  In
> particular, if design shows that being a root only feature is the only
> sane way of doing this, it should be a root only feature.  (I hope this
> is not the case, but it shouldn't cloud the judgement of a design).

I would argue that security is an integral part of the architecture and
should not be retrofitted into it.

Is it really a good design if the only sane way to implement it is
making it a root-only feature? I think not. Designing security policies
for pieces of software that don't have the infrastructure for them is
costly and that cost should be accounted as part of the overall cost of
the solution rather than added to it in a second stage.


> (note, both before implement happens).

That is ideal but realistically in many cases nobody is able to produce
a design before the implementation happens. There is plenty of articles
written about this since the 90s / early 00s.

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