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

Re: [Xen-devel] [PATCH v5.1 2/8] xen: restrict: use xentoolcore_restrict_all



On Fri, 27 Oct 2017, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH v5.1 2/8] xen: restrict: use 
> xentoolcore_restrict_all"):
> > On Fri, 20 Oct 2017, Ian Jackson wrote:
> ...
> > > Drop individual use of xendevicemodel_restrict and
> > > xenforeignmemory_restrict.  These are not actually effective in this
> > > version of qemu, because qemu has a large number of fds open onto
> > > various Xen control devices.
> ...
> > Wait, if the compat stub returns error, and this patch removed the code
> > to check for ENOTTY, doesn't it prevent any QEMU compiled against older
> > Xen from working?
> > 
> > Or am I missing something?
> 
> You are right, but this is intended.  The paragraph I quote in the
> commit message above is intended to explain.
> 
> That is: without xentoolcore_restrict_all, -xen-domid-restrict is a
> booby-trap.  It does not actually prevent a compromised qemu from
> doing anything.  So there is no reason to pass it in such a
> configuration.  If you do pass it it is better for the domain startup
> to fail, than for it to carry on without the restriction.
> 
> The only reason I am not saying someone should be issuing an advisory
> is that this feature was never supported by any of the Xen toolstacks.

Ah, right. And libxl has never passed -xen-domid-restrict in previous
releases, so we are OK.

Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

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

 


Rackspace

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