GPF when doing jail -r, possibly an use-after-free
Bjoern A. Zeeb
bzeeb-lists at lists.zabbadoz.net
Mon Jul 9 06:07:08 UTC 2012
On 9. Jul 2012, at 06:01 , Mikolaj Golub wrote:
>
> On Sun, 8 Jul 2012 20:52:55 +0000 Bjoern A. Zeeb wrote:
>
> BAZ> Situation 1)
>
> 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
>
> BAZ> Situation 2)
>
> BAZ> epairNa is in base, eiparNb is jail foo
> BAZ> you are in jail foo and type epairNb destroy; that should not be allowed
>
> BAZ> Situation 3)
>
> BAZ> epairNa is in base, eiparNb is jail foo
> BAZ> you are in base and type ifconfig epairNa destroy
>
> 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.
>
> 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.
>
> CURVNET_SET_QUIET() is used in the current version of the patch so I suppose I
> can commit it.
>
> 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.
>
> 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.
>
> --
> Mikolaj Golub
> _______________________________________________
> freebsd-virtualization at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe at freebsd.org"
--
Bjoern A. Zeeb You have to have visions!
It does not matter how good you are. It matters what good you do!
More information about the freebsd-virtualization
mailing list