From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Marczykowski Subject: Re: [PATCH 1/2] libxl: do not assume Dom0 backend while listing disks and nics Date: Wed, 08 May 2013 01:13:28 +0200 Message-ID: <51898A98.4070001@invisiblethingslab.com> References: <20864.61051.771893.780433@mariner.uk.xensource.com> <1367408595.3142.711.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5019431884851572668==" Return-path: In-Reply-To: <1367408595.3142.711.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============5019431884851572668== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2RUQRQEFSWXORCRVRULOU" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RUQRQEFSWXORCRVRULOU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01.05.2013 13:43, Ian Campbell wrote: > On Wed, 2013-05-01 at 11:29 +0100, Ian Jackson wrote: >> Marek Marczykowski writes ("[PATCH 1/2] libxl: do not assume Dom0 back= end while listing disks and nics"): >>> One more place where code assumed that all backends are in dom0. List= >>> devices in domain device/ tree, instead of backend/ of dom0. >>> Additionally fix libxl_devid_to_device_{nic,disk} to fill backend_dom= id >>> properly. >> >> After this change, can a guest cause a backend to be leaked when the >> domain is destroyed ? If it deletes the contents of the frontend >> directory in xenstore, I think the device will no longer show up in >> the lists and so won't be deleted when the guest goes away. >=20 > I would have hoped that XS perms on key nodes, like the backend link > would prevent this, but since the actual frontend directory is guest > writeable I rather expect we can't make this so. >=20 >> Would iterating over all domains looking for backends for a particular= >> frontend domain work ? That would allow a rogue guest to cause >> entries to appear in the list of course, by pretending to be a >> backend domain... >=20 > Or should libxl keep a shadow list of devices for the domain in its > private xs directory? IMHO listing frontend "device/$TYPE" entries is sufficient compromise. Downsides: 1. rogue frontend domain will be able to make leak backend xenstore entri= es Upsides: 1. all devices will be listed/cleaned up on destroy, not only those dom0-backed (assuming no downside "1" occurred) 2. will not introduce additional complexity (either scanning all backends= , or keeping *in sync* additional shadow copy of devices) The current state (without this patch) will always miss all non-dom0 back= ed devices, not only in case of rogue domain. Additionally IMHO possible lea= k (downside 1) is bearable b/c backend driver watches frontend "state" entr= y and if it disappear - will clean up the device. So the leak is only xenstore entries, not any real device. --=20 Best Regards, Marek Marczykowski Invisible Things Lab ------enig2RUQRQEFSWXORCRVRULOU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRiYqYAAoJENuP0xzK19csRFUH/RLzyk6pLQdXW8FcCsrJ0PFg XQXOkgG5MtOw0q8fZF3JFmHzV4dWjS4cS5DdXbcX8GQdWDAFchqSo0L4Mc7JQyNC Tc0HD9ENyaM4Fy9nNIJdaRttlvSqdWChbE/Ll0JFFEz9oL+fyQFzE90si1cW57Jt uzXejWNrc4LG2zZn9JuOIyQb3mT0N8aKGMSYfU0jbhGpzqR+5I/77VzbZNEkUqEz rQBNLAJ+soA7ZlXYrj1yXauxWSqfIHAs5/ZWo15HJJld5JKdJow+snwcjQ9Zvuek BGDKGsviZ0RHqEKRmDtFkh8IjzPVMhBw9ZTj1fe4ptBR9ByTB2BRVdB14qkzORw= =AVs6 -----END PGP SIGNATURE----- ------enig2RUQRQEFSWXORCRVRULOU-- --===============5019431884851572668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5019431884851572668==--