[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

>> +## 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?

>> +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).

>> +### Network
>>   +If QEMU runs in its own network namespace, it can't open the tap
>> +device itself because the interface won't be visible outside of its
>> +own namespace. So instead, have the toolstack open the device and pass
>> +it as an fd on the command-line:
>>   -2) a user named "xen-qemuuser-shared"
>> -As a fall back if both 1) fails, libxl will use a single user for
>> -all QEMU instances. The user is named xen-qemuuser-shared. This is
>> -less secure but still better than running QEMU as root. Using this is as
>> -simple as creating just one more user on your host:
>> +    -device rtl8139,netdev=tapnet0,mac=... -netdev
>> tap,id=tapnet0,fd=<tapfd>
>>   -adduser --no-create-home --system xen-qemuuser-shared
>> +### VNC
>>   +If QEMU runs in its own network namespace, it is not straightforward
>> +to listen on a TCP socket outside of its own network namespace. One
>> +option would be to use VNC over a UNIX socket:
>>   -3) root
>> -As a last resort, libxl will start QEMU as root.
>> +    -vnc unix:/var/run/xen/vnc-<domid>
>>   +However, this would break functionality in the general case; I think
>> +we need to have the toolstack open a socket and pass the fd to QEMU
>> +(which requires changes to QEMU).
>>   -Please note that running QEMU as non-root causes several features like
>> -migration and PCI passthrough to not work properly and may prevent
>> the guest
>> -from booting.
>>
> 
> Although there are still a lot of todos, this looks generally good and
> is a big improvement on the previous document.

Thanks.

I think v2 I'll also remove the HOWTO-ish stuff from xl.cfg, which is
inappropriate for a man page, and refer to this document instead.

 -George

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.