Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On 03/23/2018 10:53 AM, George Dunlap wrote:
> On 03/23/2018 09:41 AM, Ross Lagerwall wrote:
> > On 03/22/2018 06:24 PM, George Dunlap wrote:
> > snip
> > > -for ((i=1; i<65536; i++))
> > > +# Introduction
> > > +
> > > +# Setup
> > > +
> > > +## Getting the right versions of software
> > > +
> > > +Linux 4.XX
> > (For dom0 kernel...)
> >
> > Requires 4.11 for the ability to restrict dmop calls.
> Thanks, I'll update this section.
>
> > > +
> > > +Xen 4.XX
> > Requires 4.11 to get required dmop calls to make VGA work.
> On reflection, there's probably not much point in including this: The
> document will contain the state of functionality of the version of Xen
> that contains it.
Agreed.

> > > +## Domain config changes
> > > +
> > > +The core domain config change is to add the following line to the
> > > +domain configuration:
> > > +
> > > +    dm_restrict=1
> > > +
> > > +This will perform a number of restrictions, outlined below in the
> > > +'Technical details' section.
> > > +
> > > +Remove non-functioning default features:
> > > +
> > > +    vga="none"
> > I'm not sure what this means?
> Well it's under "domain config changes"; if you add this to your xl
> domain config, then QEMU will not provide any emulated VGA devices.
>
> But it sounds like this issue has been fixed in 4.11 anyway, so perhaps
> we can remove this section?
Yes, it can be removed.

> > > +Other features expected not to work include:
> > > +* Inserting a new cdrom while the guest is running (xl cdrom-insert)
> > > +* migration / save / restore
> > The above two features could be made to work if the toolstack drives
> > QEMU correctly.
> Yes; I'm trying to use this document for several purposes:
>
> * "HOWTO" -- useful for people who want to experiment with the feature.
> For this I want to include what works and what doesn't work
>
> * Design doc -- a place to discuss / record what to do and how to do it
> (a lot of these are independent, so the work could be shared or at least
> passed around between people).
>
> * Todo list -- a place to identify work that still needs to be done.
>
> But I could try to make it clearer that these are "todo" items, and that
> "PCI" is further down the importance list than the others.
>
>
> > > +### Xen restrictions
> > > +
> > > +'''Description''': Close and restrict Xen-related file descriptors.
> > > +Specifically, make sure that only one `privcmd` instance is open, and
> > > +that the IOCTL_EVTCHN_RESTRICT_DOMID ioctl has been called.
> > Just to clarify, we call IOCTL_PRIVCMD_RESTRICT on the `privcmd` fds and
> > IOCTL_EVTCHN_RESTRICT_DOMID on the evtchn fds which remain open. There
> > is no requirement to have only one instance of each.
> >
> > > +
> > > +XXX Also, make sure that only one `xenstore` fd remains open, and that
> > > +it's restricted.
> > The current implementation closes _all_ xenstore fds and doesn't need to
> > make use of xenstore after going into restricted mode.
> Ack (and with spelling mistakes)
>
>
> > > +### Network namespacing
> > > +
> > > +Enter QEMU into its own network namespace (in addition to mount & IPC
> > > +namespaces).  Basically change the 'unshare' call to be as follows:
> > > +
> > > +    unshare(CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWIPC)
> > It might be clearer if this was merged with the other Namespacing
> > section or at least put immediately afterwards.
> Part of my goal here was to list things in a "low-hanging-fruit" order.
> Since QEMU doesn't use mount or IPC namespaces, that can be done
> immediately.  Using a new network namespace requires changing how
> network devices are set up, and possibly making code changes to QEMU so
> that it can still listen on network sockets; hence putting this lower
> down the list (followed by the two things that would need to be fixed if
> it were implemented).
OK, fair enough.

--
Ross Lagerwall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel