From owner-freebsd-virtualization@FreeBSD.ORG Sun Jul 8 20:47:54 2012 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C2CC106564A for ; Sun, 8 Jul 2012 20:47:54 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 076558FC12 for ; Sun, 8 Jul 2012 20:47:53 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so10665138wgb.31 for ; Sun, 08 Jul 2012 13:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=jnzAR8B/wejl2sWI+BFhD0jMQ32nDZoLsjRC65BUeMA=; b=eoVzaEzE9ppnFbcZj9HBKWScuFMkROf1qf/7EcaX0G0ulmsFaqXK0qgFFsWnbKEdAi Nz2pRr4wB5fDJheQRPTGSD6uXXlDWBvafbmpHLEu3ttoiVNt48Hbc1MOLJBzMLooxlqu 9vx/66kfEoHVScy5850EtLQ/aaj70PbL7p/hDwK4uM121Yfeo8722Rz4X34n3iuiQODs ZNQ8UHsbCE8RGhGxu+PDSErSLvuLQRqM3Xot10bml/TlBmsDAVl9ecPvJ63a7WJC9fYn Cbzs0yemE1eKwionxchSYoLq6uVgmwjhy9yQ7ueeLdAUOsxbY6obm5pSrNSAFYcaNHhX esVw== Received: by 10.216.24.85 with SMTP id w63mr3717255wew.145.1341780034290; Sun, 08 Jul 2012 13:40:34 -0700 (PDT) Received: from localhost ([95.69.175.25]) by mx.google.com with ESMTPS id eu4sm19731426wib.2.2012.07.08.13.40.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 13:40:32 -0700 (PDT) From: Mikolaj Golub To: "Bjoern A. Zeeb" 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> X-Comment-To: Bjoern A. Zeeb Sender: Mikolaj Golub Date: Sun, 08 Jul 2012 23:40:30 +0300 In-Reply-To: (Bjoern A. Zeeb's message of "Sat, 7 Jul 2012 20:38:23 +0000") Message-ID: <86obnqq94x.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: d@delphij.net, FreeBSD virtualization mailing list Subject: Re: GPF when doing jail -r, possibly an use-after-free X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 20:47:54 -0000 On Sat, 7 Jul 2012 20:38:23 +0000 Bjoern A. Zeeb wrote: BAZ> On 6. Jul 2012, at 05:53 , Mikolaj Golub wrote: >> >> On Thu, 5 Jul 2012 20:21:53 +0000 Bjoern A. Zeeb wrote: >> >> BAZ> On 5. Jul 2012, at 19:53 , Mikolaj Golub wrote: >> >>>> >>>> On Thu, 05 Jul 2012 12:18:20 -0700 Xin Li wrote: >>>> >>>> XL> Hi, Mikolaj, >>>> >>>> XL> On 07/04/12 00:00, Mikolaj Golub wrote: >>>>>> Is this observed after destroying epair? There is an issue with >>>>>> epair: on destroy, when epair_clone_destroy() calls >>>>>> ether_ifdetach() for its second half it does not switch to its vnet >>>>>> and if_detach_internal() can't find the interface and just returns. >>>>>> As a result V_ifnet list is left with dead reference. >>>> >>>> XL> Yes. >>>> >>>>>> http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-January/000628.html >>>>>> >>>>>> Here is an updated patch against CURRENT: >>>>>> >>>>>> http://people.freebsd.org/~trociny/if_epair.c.epair_clone_destroy.1.patch >>>> >>>> XL> Your >>>>>> >>>> XL> patch did fixed the problem, thanks! Are you going to commit it >>>> XL> against -HEAD and then MFC after a while? >>>> >>>> I would like Bjoern review it before me committing, or at least tell he does >>>> not mind, if he does not have time to review -) >> >> BAZ> To me the patch looks wrong; I am wondering if someone broke some other central >> BAZ> assumptions but given I cannot currently spend time on this and if it fixes things >> BAZ> feel free to go ahead. >> >> If you told what looks wrong I could try to dig at that direction and might be >> back with a better solution, instead of committing a presumably wrong fix. BAZ> sorry; vnet.c:vnet_destroy() should dtrt already wrt to interfaces moving to parents BAZ> and being detached. But this is not the issue with vnet_destroy() not moving interfaces to parents. It does move them. It is with destroying epair. When epair that has its ends in different vnets is destroyed, and ether_ifdetach() is called for the second end without switching to its vnet it fails to find the iface in the wrong vnet and just silently returns (which I think is also wrong: if_detach_internal() should panic here). As a result the pointer is not removed from vnet ifnet list. And later, when someone is traversing this list and tries to access the pointer (this is often vnet_destroy(), which is usually called after removing interfaces, but might be e.g. ifconfig) dead pointer dereference occurs. My patch just makes epair_clone_destroy() switch to the proper vnet before calling ether_ifdetach(). Or have I missed your point? -- Mikolaj Golub From owner-freebsd-virtualization@FreeBSD.ORG Sun Jul 8 20:53:00 2012 Return-Path: Delivered-To: freebsd-virtualization@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F450106566C; Sun, 8 Jul 2012 20:53:00 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 300678FC1F; Sun, 8 Jul 2012 20:53:00 +0000 (UTC) Received: from dhcp-128-232-132-170.eduroam.csx.cam.ac.uk (dhcp-128-232-132-170.eduroam.csx.cam.ac.uk [128.232.132.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id 3524B25D3891; Sun, 8 Jul 2012 20:52:57 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <86obnqq94x.fsf@kopusha.home.net> Date: Sun, 8 Jul 2012 20:52:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <50CFED43-7789-4F27-9EC7-85268B7F23D4@lists.zabbadoz.net> 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> <86obnqq94x.fsf@kopusha.home.net> To: Mikolaj Golub X-Mailer: Apple Mail (2.1084) Cc: d@delphij.net, FreeBSD virtualization mailing list Subject: Re: GPF when doing jail -r, possibly an use-after-free X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 20:53:00 -0000 On 8. Jul 2012, at 20:40 , Mikolaj Golub wrote: >=20 > On Sat, 7 Jul 2012 20:38:23 +0000 Bjoern A. Zeeb wrote: >=20 > BAZ> On 6. Jul 2012, at 05:53 , Mikolaj Golub wrote: >=20 >>>=20 >>> On Thu, 5 Jul 2012 20:21:53 +0000 Bjoern A. Zeeb wrote: >>>=20 >>> BAZ> On 5. Jul 2012, at 19:53 , Mikolaj Golub wrote: >>>=20 >>>>>=20 >>>>> On Thu, 05 Jul 2012 12:18:20 -0700 Xin Li wrote: >>>>>=20 >>>>> XL> Hi, Mikolaj, >>>>>=20 >>>>> XL> On 07/04/12 00:00, Mikolaj Golub wrote: >>>>>>> Is this observed after destroying epair? There is an issue with >>>>>>> epair: on destroy, when epair_clone_destroy() calls >>>>>>> ether_ifdetach() for its second half it does not switch to its = vnet >>>>>>> and if_detach_internal() can't find the interface and just = returns. >>>>>>> As a result V_ifnet list is left with dead reference. >>>>>=20 >>>>> XL> Yes. >>>>>=20 >>>>>>> = http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-January/000= 628.html >>>>>>>=20 >>>>>>> Here is an updated patch against CURRENT: >>>>>>>=20 >>>>>>> = http://people.freebsd.org/~trociny/if_epair.c.epair_clone_destroy.1.patch >>>>>=20 >>>>> XL> Your >>>>>>>=20 >>>>> XL> patch did fixed the problem, thanks! Are you going to commit = it >>>>> XL> against -HEAD and then MFC after a while? >>>>>=20 >>>>> I would like Bjoern review it before me committing, or at least = tell he does >>>>> not mind, if he does not have time to review -) >>>=20 >>> BAZ> To me the patch looks wrong; I am wondering if someone broke = some other central >>> BAZ> assumptions but given I cannot currently spend time on this and = if it fixes things >>> BAZ> feel free to go ahead. >>>=20 >>> If you told what looks wrong I could try to dig at that direction = and might be >>> back with a better solution, instead of committing a presumably = wrong fix. >=20 > BAZ> sorry; vnet.c:vnet_destroy() should dtrt already wrt to = interfaces moving to parents > BAZ> and being detached. >=20 > But this is not the issue with vnet_destroy() not moving interfaces to > parents. It does move them. It is with destroying epair. When epair = that has > its ends in different vnets is destroyed, and ether_ifdetach() is = called for > the second end without switching to its vnet it fails to find the = iface in the > wrong vnet and just silently returns (which I think is also wrong: > if_detach_internal() should panic here). As a result the pointer is = not > removed from vnet ifnet list. And later, when someone is traversing = this list > and tries to access the pointer (this is often vnet_destroy(), which = is > usually called after removing interfaces, but might be e.g. ifconfig) = dead > pointer dereference occurs. >=20 > My patch just makes epair_clone_destroy() switch to the proper vnet = before > calling ether_ifdetach(). >=20 > Or have I missed your point? Maybe: Situation 1) epairNa is in base, eiparNb is jail foo stop jail foo: jail -r foo both epairN[ab] will live in base and can be destiryed without = vnet switching Situation 2) epairNa is in base, eiparNb is jail foo you are in jail foo and type epairNb destroy; that should not = be allowed Situation 3) epairNa is in base, eiparNb is jail foo you are in base and type ifconfig epairNa destroy This is your case ... I am not sure what I'd expect in this = case, especailly given epair is special... You probably are right. Ideally I'd not allow it to be destroyed unless both are in the if_home_vnet. However it seems we allow this; so in that case I definitively make sure to use the CURVNET_SET_QUIET() version to avoid the expected noise otherwise. The moment cloners will handle this it'll all be centrally managed and individual device drivers shouldn't need to worry about it anymore. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-virtualization@FreeBSD.ORG Mon Jul 9 06:01:30 2012 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97AE1106566B for ; Mon, 9 Jul 2012 06:01:30 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9368FC0A for ; Mon, 9 Jul 2012 06:01:29 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so2090026wib.13 for ; Sun, 08 Jul 2012 23:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=ev9SlTeoY8sB/D1y71wWTV+Jfin/7hp1l2S0T9TD+MU=; b=m98eeDV4ElzLERaVZeK/EqaDS1/Xenj1w7Ux55WDKdDp/hD6gwlq2s9MCjSAxOfIz5 i/iZ1CxY4TtGoMu0kWsJ82rEymKXTclN3EMAgUnGmcLFAs8ZkGzMA2XMiWg4hb1NdrPn WvG6IlK07ZBYURWhuG0OJVuaJ+SMZ/D9R99Ii9mRHN+ixp+OFi8darfm810QXPMYhfXO RcWpz/vwwA9sA2dWG5Tn47eQU9jodwGEds5ZUoPJpZxT8XUTa4FlSsrNP+gXYY479n5D gz0K0w6q384A1KLYUvSINsxlsiS+hS+N7LHcTrHH/pT/hUpgLQQ4VK4rQLUFSuEj8crU 3DOw== Received: by 10.216.45.211 with SMTP id p61mr15258275web.188.1341813686946; Sun, 08 Jul 2012 23:01:26 -0700 (PDT) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPS id ch9sm32379373wib.8.2012.07.08.23.01.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 23:01:25 -0700 (PDT) From: Mikolaj Golub To: "Bjoern A. Zeeb" Organization: TOA Ukraine 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> <86obnqq94x.fsf@kopusha.home.net> <50CFED43-7789-4F27-9EC7-85268B7F23D4@lists.zabbadoz.net> Sender: Mikolaj Golub Date: Mon, 09 Jul 2012 09:01:23 +0300 In-Reply-To: <50CFED43-7789-4F27-9EC7-85268B7F23D4@lists.zabbadoz.net> (Bjoern A. Zeeb's message of "Sun, 8 Jul 2012 20:52:55 +0000") Message-ID: <86liit8ocs.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: d@delphij.net, FreeBSD virtualization mailing list Subject: Re: GPF when doing jail -r, possibly an use-after-free X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 06:01:30 -0000 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. 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 From owner-freebsd-virtualization@FreeBSD.ORG Mon Jul 9 06:07:08 2012 Return-Path: Delivered-To: freebsd-virtualization@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EE7F1065670; Mon, 9 Jul 2012 06:07:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 149098FC0A; Mon, 9 Jul 2012 06:07:08 +0000 (UTC) Received: from dhcp-128-232-132-170.eduroam.csx.cam.ac.uk (dhcp-128-232-132-170.eduroam.csx.cam.ac.uk [128.232.132.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id DA97725D387C; Mon, 9 Jul 2012 06:07:06 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <86liit8ocs.fsf@in138.ua3> Date: Mon, 9 Jul 2012 06:07:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <86obnqq94x.fsf@kopusha.home.net> <50CFED43-7789-4F27-9EC7-85268B7F23D4@lists.zabbadoz.net> <86liit8ocs.fsf@in138.ua3> To: Mikolaj Golub X-Mailer: Apple Mail (2.1084) Cc: d@delphij.net, FreeBSD virtualization mailing list Subject: Re: GPF when doing jail -r, possibly an use-after-free X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 06:07:08 -0000 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! From owner-freebsd-virtualization@FreeBSD.ORG Mon Jul 9 11:07:23 2012 Return-Path: Delivered-To: freebsd-virtualization@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDF04106564A for ; Mon, 9 Jul 2012 11:07:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A78C98FC0A for ; Mon, 9 Jul 2012 11:07:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q69B7N2F075602 for ; Mon, 9 Jul 2012 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q69B7NrE075599 for freebsd-virtualization@FreeBSD.org; Mon, 9 Jul 2012 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Jul 2012 11:07:23 GMT Message-Id: <201207091107.q69B7NrE075599@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-virtualization@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-virtualization@FreeBSD.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:07:23 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/167551 virtualization[vimage] Fatal trap 12 jails, vimage, ifconfig destroy o kern/165252 virtualization[vimage] [pf] [panic] kernel panics with VIMAGE and PF o kern/161094 virtualization[vimage] [pf] [panic] kernel panic with pf + VIMAGE wh o kern/160541 virtualization[vimage][pf][patch] panic: userret: Returning on td 0x o kern/160496 virtualization[vimage] [pf] [patch] kernel panic with pf + VIMAGE f kern/152047 virtualization[vimage] [panic] TUN\TAP under jail with vimage crashe o kern/148155 virtualization[vimage] [pf] Kernel panic with PF/IPFilter + VIMAGE k a kern/147950 virtualization[vimage] [carp] VIMAGE + CARP = kernel crash s kern/143808 virtualization[pf] pf does not work inside jail a kern/141696 virtualization[rum] [vimage] [panic] rum(4)+ vimage = kernel panic 10 problems total. From owner-freebsd-virtualization@FreeBSD.ORG Mon Jul 9 20:48:03 2012 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B618110656F8 for ; Mon, 9 Jul 2012 20:48:03 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 3797D8FC14 for ; Mon, 9 Jul 2012 20:48:03 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so2725273wib.13 for ; Mon, 09 Jul 2012 13:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=qagJ+7qJZHJrNloq9w/25YH3vp/PwLmqSrGpq0qVPTE=; b=HwUobJETYU2ug2zgfBouwYkPuYNaniMtZmdzwU00rt+giFZgMlW6b221JD6tVfzq9H /sNI4Mwr/ZmBOdT3s2+hXE1IVqQU2K0psDcglr1M6aC6uot5VuOIgSDQBs5RFSradi6P G5Uu2syLOR5uVWJx4nhR9FuMztkPwGbEXk1klcFQeFn6c4uUFpFxRCkQphj2WS/w/CnA j9Lt/uy7x0ZE6o1mF0+X/5xfcKmspnOeAIHwPVRpgKAMsL0M10B8IK/ZZGyzEfwwct9O BBJwCSisE2BFXTZ6g518nRYdOxOSqRS3/IZzt9VKd0F3SZ01wdzb2VJckn8bHvmanN89 kW0A== Received: by 10.180.98.200 with SMTP id ek8mr3680812wib.0.1341866882339; Mon, 09 Jul 2012 13:48:02 -0700 (PDT) Received: from localhost ([95.69.175.25]) by mx.google.com with ESMTPS id l5sm37511397wix.5.2012.07.09.13.47.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 13:47:58 -0700 (PDT) From: Mikolaj Golub To: "Bjoern A. Zeeb" 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> <86obnqq94x.fsf@kopusha.home.net> <50CFED43-7789-4F27-9EC7-85268B7F23D4@lists.zabbadoz.net> <86liit8ocs.fsf@in138.ua3> X-Comment-To: Bjoern A. Zeeb Sender: Mikolaj Golub Date: Mon, 09 Jul 2012 23:47:55 +0300 In-Reply-To: (Bjoern A. Zeeb's message of "Mon, 9 Jul 2012 06:07:05 +0000") Message-ID: <86wr2cveys.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: d@delphij.net, FreeBSD virtualization mailing list Subject: Re: GPF when doing jail -r, possibly an use-after-free X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 20:48:03 -0000 On Mon, 9 Jul 2012 06:07:05 +0000 Bjoern A. Zeeb wrote: BAZ> 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. BAZ> Get it in for now; it helps people. We should keep the other things in mind and BAZ> write down a proper policy; it's more interesting as you can do other things with BAZ> cloners you can create inside a vnet as well, today and later. Thank you for the discussion. The patch is committed. -- Mikolaj Golub From owner-freebsd-virtualization@FreeBSD.ORG Mon Jul 9 20:52:16 2012 Return-Path: Delivered-To: freebsd-virtualization@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 580B61065673; Mon, 9 Jul 2012 20:52:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 33C628FC22; Mon, 9 Jul 2012 20:52:16 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id E09CA11CEF; Mon, 9 Jul 2012 13:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1341867136; bh=hv+OPTjlq/4GEAclF/JOq9ypfnzW/ANPvl4QKFV19Jo=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=KJJaVFIZS5Yvz+fVmU/M01XmZMCpn+A2rzkHSl+f7tlV1a5PpKC3JzCfO03YsIsnh 2quRsVTnlqv2WCULZHjGwxVeefuYcPGcWFj1x+B5VY2lgWf8HqvX6Vix3Wcz7i2M9P hkou+l/yeN5sR+o4PfA1vzNQozTG9mehDhUXWYRQ= Message-ID: <4FFB447F.6080508@delphij.net> Date: Mon, 09 Jul 2012 13:52:15 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Mikolaj Golub 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> <86obnqq94x.fsf@kopusha.home.net> <50CFED43-7789-4F27-9EC7-85268B7F23D4@lists.zabbadoz.net> <86liit8ocs.fsf@in138.ua3> <86wr2cveys.fsf@kopusha.home.net> In-Reply-To: <86wr2cveys.fsf@kopusha.home.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , d@delphij.net, FreeBSD virtualization mailing list Subject: Re: GPF when doing jail -r, possibly an use-after-free X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 20:52:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/09/12 13:47, Mikolaj Golub wrote: > > On Mon, 9 Jul 2012 06:07:05 +0000 Bjoern A. Zeeb wrote: > > BAZ> 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. > > BAZ> Get it in for now; it helps people. We should keep the other > things in mind and BAZ> write down a proper policy; it's more > interesting as you can do other things with BAZ> cloners you can > create inside a vnet as well, today and later. > > Thank you for the discussion. The patch is committed. Thanks! Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+0R/AAoJEG80Jeu8UPuzhdUIAKYXIbwMSxEMmtqZVcLuWXqx 50f/ni+zkXkGgECMGclWcD5jDwJCCPBsUPg1aOl35pXlVZEKQY+gbMU53olz83fn vkRZmS6PBPYgYY/vT0W8EmCk1Sb/DeGVnrltVPnHxOkQkcV6u0c8xzxxX36H7hFl oJDYq3bXfEOQTlJYQHt42oPtJrPyAlG+yCQSIp2YbxZhlU+jF2qakG1FyqrP9jX8 rQAcfw0uLKGcI1JBfhzcW635CFVlTQZCkLWi//Djb0Wo/YgXpKD9fGWA54iN8qEm bd6Io7w9vF6otk0JEkmySYEvAceOx0Ae8M8oMm+q4abUYnOJZtNyYul7IhGDkVM= =Yr4X -----END PGP SIGNATURE-----