Date: Mon, 9 Jul 2012 06:07:05 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Mikolaj Golub <trociny@freebsd.org> Cc: d@delphij.net, FreeBSD virtualization mailing list <freebsd-virtualization@FreeBSD.org> Subject: Re: GPF when doing jail -r, possibly an use-after-free Message-ID: <A8594672-5F62-4809-BBE7-7C2C3FAFE3C3@lists.zabbadoz.net> In-Reply-To: <86liit8ocs.fsf@in138.ua3> References: <4FF32FC4.6020701@delphij.net> <86wr2kau38.fsf@in138.ua3> <4FF5E87C.2020908@delphij.net> <86r4sqasrt.fsf@kopusha.home.net> <672D93D3-D4B1-432E-AE53-98E6C05B8BE4@lists.zabbadoz.net> <86zk7da10y.fsf@in138.ua3> <E909B0C0-F4DE-4110-B151-98FAC9330B82@lists.zabbadoz.net> <86obnqq94x.fsf@kopusha.home.net> <50CFED43-7789-4F27-9EC7-85268B7F23D4@lists.zabbadoz.net> <86liit8ocs.fsf@in138.ua3>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9. Jul 2012, at 06:01 , Mikolaj Golub wrote: >=20 > On Sun, 8 Jul 2012 20:52:55 +0000 Bjoern A. Zeeb wrote: >=20 > BAZ> Situation 1) >=20 > BAZ> epairNa is in base, eiparNb is jail foo > BAZ> stop jail foo: jail -r foo > BAZ> both epairN[ab] will live in base and can be destiryed = without vnet switching >=20 > BAZ> Situation 2) >=20 > BAZ> epairNa is in base, eiparNb is jail foo > BAZ> you are in jail foo and type epairNb destroy; that = should not be allowed >=20 > BAZ> Situation 3) >=20 > BAZ> epairNa is in base, eiparNb is jail foo > BAZ> you are in base and type ifconfig epairNa destroy >=20 > BAZ> This is your case ... I am not sure what I'd expect in = this case, > BAZ> especailly given epair is special... You probably are = right. > BAZ> Ideally I'd not allow it to be destroyed unless both are = in the > BAZ> if_home_vnet. However it seems we allow this; so in that = case > BAZ> I definitively make sure to use the CURVNET_SET_QUIET() = version > BAZ> to avoid the expected noise otherwise. >=20 > It looks like epair was expected to allow this, because in non-patched = version > it already did switching before freeing the interface. It just did not = switch > bere detaching. >=20 > CURVNET_SET_QUIET() is used in the current version of the patch so I = suppose I > can commit it. >=20 > But if you think that just not allowing to destroy unless both ends = are in the > f_home_vnet is a preferred solution and it is not late to change this = I can > provide the patch. Get it in for now; it helps people. We should keep the other things in = mind and write down a proper policy; it's more interesting as you can do other = things with cloners you can create inside a vnet as well, today and later. >=20 > BAZ> The moment cloners will handle this it'll all be centrally = managed > BAZ> and individual device drivers shouldn't need to worry about it = anymore. >=20 > --=20 > Mikolaj Golub > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to = "freebsd-virtualization-unsubscribe@freebsd.org" --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8594672-5F62-4809-BBE7-7C2C3FAFE3C3>