[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |