From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 06:11:46 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04ED6F03 for ; Sun, 12 Oct 2014 06:11:46 +0000 (UTC) Received: from frv190.fwdcdn.com (frv190.fwdcdn.com [212.42.77.190]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B53A3A91 for ; Sun, 12 Oct 2014 06:11:45 +0000 (UTC) Received: from [10.10.2.23] (helo=frv198.fwdcdn.com) by frv190.fwdcdn.com with esmtp ID 1XdC7p-000Aa6-Pf for freebsd-arch@freebsd.org; Sun, 12 Oct 2014 08:55:25 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=Ji1x2PvyrreYoQl+ZVCGe3d/gAWVgAEvdRv9Zm15A3c=; b=UwPXueYZkg+7Nn7mELgaYSaLwLbsQ4YID31KUNjbjEu7l6jGMyOIjHWiF9ccnp4c7Aj207T42TTbgCi0k3musdeq+f21YzwTlZOEbVBDP+3Dhm5CTWnmr9kmWBsts86sHl77mRJfGksTUf4kwffMBigd8UAK7dTT5r4BChts5qM=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv198.fwdcdn.com with smtp ID 1XdC7d-000AW1-Lc for freebsd-arch@freebsd.org; Sun, 12 Oct 2014 08:55:13 +0300 Date: Sun, 12 Oct 2014 08:55:13 +0300 From: wishmaster Subject: Re[2]: Enabling VIMAGE by default for FreeBSD 11? To: "Alexander V. Chernikov" X-Mailer: mail.ukr.net 5.0 Message-Id: <1413092963.907920156.b727jzia@frv34.fwdcdn.com> In-Reply-To: References: MIME-Version: 1.0 Received: from artemrts@ukr.net by frv34.fwdcdn.com; Sun, 12 Oct 2014 08:55:13 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: Craig Rodrigues , freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 06:11:46 -0000 --- Original message --- From: "Alexander V. Chernikov" Date: 11 October 2014, 23:20:39 > > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > > > Hi, > > > > What action items are left to enable VIMAGE by default for FreeBSD 11? > Are there any tests results showing performance implications on different network-related workloads? https://wiki.freebsd.org/NetworkingPerformanceProject Last item: "Add VNET to any of the above as well." > > > > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. > > > > -- > > Craig > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 06:15:15 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8652D362; Sun, 12 Oct 2014 06:15:15 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A49C9B37; Sun, 12 Oct 2014 06:15:14 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x12so6547221wgg.8 for ; Sat, 11 Oct 2014 23:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yuM3YANeOSYfANJH9xy9ZMXAVOHEfnV+xZntt4/8xyA=; b=Fdb6VLhq9d/vNyrV2n+l7gC01f7f3JJMHwkD8GiwficlCbOVY51MIDBaOtWxjaoc43 yPCrxLKOs1e2oBMJ+nTkOYJcz8smlkUEBlksnq01aVSagxpSSw93zAKhni4mBjN9EJuU CifGZcWKqoBU0zn7qDzXBDnPWa50k1TbL/ZFgVPQnz7+2GDc01V8rbVROItEcqAwQcnv VYq4BkjF/JLqr3F1S8KqqI+QfmEltTUTzgH30YKyQXFRyIPokugDarkTzdCaswDqUGYJ 1Xqp0owMZI0ABuuTVFJ2AklDGP7r48LzzyYF55NhWb01vCrzFF9s0M05eYwqZVK4+Smf CKjA== MIME-Version: 1.0 X-Received: by 10.194.62.166 with SMTP id z6mr14171300wjr.44.1413094512897; Sat, 11 Oct 2014 23:15:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 11 Oct 2014 23:15:12 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Oct 2014 23:15:12 -0700 X-Google-Sender-Auth: 98kzrz934N203Ay7Eqdltu6Ktzw Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Adrian Chadd To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 06:15:15 -0000 ... is it enabled by default on pcbsd? -a From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 06:53:53 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9286D978; Sun, 12 Oct 2014 06:53:53 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ADC5E37; Sun, 12 Oct 2014 06:53:52 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id ge10so5252634lab.10 for ; Sat, 11 Oct 2014 23:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MaKELVZA7nA5UTWJn7ltTITgODFi/8iVV3LxQWtvkYI=; b=xnwewU0W8QfS4R57M50NwCg/aFtLC5lll8oNTTr48KF+Rq498X7mEe6e82UkB6nNnZ Mo0MmuHB2LzmTq+gJ1oobdz8AWLdOW6b+U8I2qz9DfGx4t7Qtw9z0U1rMMc/PRZ/7ed9 MBJGTWbsDHXq20aV9qCOJ6L7mWths4qiBya3ZW62xZI8Y+BL3bL2tQHb2RLATQiNrpyL N2X6j+MzdznEOoK9pwd4VWXxOQE6aOnYVstW1pIJx67ZMoil04uVpsm/zhiIG6WNCjSu r2a/yETjgkcILKtQqDPsnxfBT2q0M6VsM5rYC6chEp68o+ihJbzgNrEYfGO/FiYB5PSI HSdQ== MIME-Version: 1.0 X-Received: by 10.152.87.101 with SMTP id w5mr631202laz.88.1413096830547; Sat, 11 Oct 2014 23:53:50 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Sat, 11 Oct 2014 23:53:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Oct 2014 23:53:50 -0700 X-Google-Sender-Auth: gFSB8faSPS9sNfJLU8Y-m9ZTnLM Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 06:53:53 -0000 On Sat, Oct 11, 2014 at 11:15 PM, Adrian Chadd wrote: > ... is it enabled by default on pcbsd? > > > -a > It was enabled in PCBSD here: https://github.com/trueos/trueos/commit/3108bbe003bc38339fbd4a26542b184b2ccb271a -- Craig From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 11:28:09 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFD81599 for ; Sun, 12 Oct 2014 11:28:09 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A34B8A86 for ; Sun, 12 Oct 2014 11:28:09 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id k15so3444317qaq.10 for ; Sun, 12 Oct 2014 04:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TnN3BnHnRkLGTFQqNir8XHX2DGLdyA6NjVUbPodbl3Q=; b=gvoya1CiWxbOFXxAWcu9P6gmJLJo39aCaVkHLEZ/bQpmGVSxtTOjAg8HwSgfOoWdt9 fe/JHlUc7PIBN6XvqKO6TxpFM35pSveOfgsWB+alVMBFSRv6Mha8DWQlJNBdt5rHqO9m otpBDEKNXhnonsnS5FrNCHuNZl2pimasFVH6Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=TnN3BnHnRkLGTFQqNir8XHX2DGLdyA6NjVUbPodbl3Q=; b=TC0A9dQD9NU+RbHJpOKhxUT8bwTdas65bOE2ezhDOvcHTPkz3q7GEaEUmJMmtkcHbq JdJFp2W42K8cSC3+Dz7KWKs4sTYUH1ylUPfCVeZJtZaYOW1+ywC9PA/0dSFwLGAwRiv9 RN6kQ3S/7TKwyOl8kggkQKANUe6lK0kBjxxIoKvciwu/cQPw0FffwYuk09IrVG8oI4ci aGYkVEuny9L5eLPyuKRUzGHd24KwfZoM9C6sGccoWd5m43+T6d2BhrqbfBoWaSlfQgAL dM6Jro0WmDXWSiOstkAfIOxnSxuH9HBQx9D1NdT6jxuHGmcJtcfas3Py+/IqtpcDddKa GeLg== X-Gm-Message-State: ALoCoQnX5Q4qGAnN+0AhgFztSXcoypJUqIxBjSmXMyD1Pdr++3tDr04LNpeYScnwrhD322xumOPG X-Received: by 10.224.115.14 with SMTP id g14mr29783488qaq.23.1413113288661; Sun, 12 Oct 2014 04:28:08 -0700 (PDT) Received: from [100.100.27.104] (149.sub-70-194-161.myvzw.com. [70.194.161.149]) by mx.google.com with ESMTPSA id y9sm9841604qaf.15.2014.10.12.04.28.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 04:28:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Jason Hellenthal X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Sun, 12 Oct 2014 06:28:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <822C5CED-1A0B-431A-B74B-CDEF3F8086F1@dataix.net> References: To: Adrian Chadd Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 11:28:10 -0000 Should also add here that for those using PF as a firewall that VIMAGE enabl= ed kernels don't play to well together.... Unless you like looking at cores a= ll day. --=20 Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal@DataIX.net JJH48-ARIN On Oct 12, 2014, at 01:15, Adrian Chadd wrote: ... is it enabled by default on pcbsd? -a _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 13:35:47 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 543CFCAE; Sun, 12 Oct 2014 13:35:47 +0000 (UTC) Received: from mail.iXsystems.com (mail.ixsystems.com [12.229.62.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F4CC958; Sun, 12 Oct 2014 13:35:46 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 63CAB816A0; Sun, 12 Oct 2014 06:35:45 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 40967-06; Sun, 12 Oct 2014 06:35:45 -0700 (PDT) Received: from [192.168.0.247] (75-130-56-30.static.kgpt.tn.charter.com [75.130.56.30]) by mail.iXsystems.com (Postfix) with ESMTPA id 8C95F81699; Sun, 12 Oct 2014 06:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1413120945; bh=1XN4/kK7/ZrYtHGJ6m+BhegSaXVbttH5VZrBeMWlr1I=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=DtfMztocFUPz5sBIH+7Inf0NCxDYrTOVV6YHLFsjCLbqz3dn4Kob9aCZQwLPpQZPt cn5iYKQq6pTB3D8WxxxrHGgSg9Hpir/BrpHCsvLY0hqEfPquHVDS7VtDX00p2FE5r7 qBH7ABYY69ZAIpkmopmU/OEdnFqv8WGN1H0zIsgI= In-Reply-To: References: User-Agent: Blue for Android MIME-Version: 1.0 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Kris Moore Date: Sun, 12 Oct 2014 09:35:41 -0400 To: Adrian Chadd Message-ID: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 13:35:47 -0000 It was for a while in 9.2, but we removed it from 10.0 and later due to stability issues we kept getting reports about. Haven't tried it since then, dont know if those issues are fixed. On Oct 12, 2014, 2:15 AM, at 2:15 AM, Adrian Chadd wrote: >... is it enabled by default on pcbsd? > > >-a >_______________________________________________ >freebsd-arch@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 16:26:13 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 679B74E6; Sun, 12 Oct 2014 16:26:13 +0000 (UTC) Received: from mail1.yamagi.org (yugo.yamagi.org [212.48.122.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29143A84; Sun, 12 Oct 2014 16:26:12 +0000 (UTC) Received: from p579a689b.dip0.t-ipconnect.de ([87.154.104.155] helo=happy.home.yamagi.org) by mail1.yamagi.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XdLy0-000CFL-VD; Sun, 12 Oct 2014 18:26:03 +0200 Date: Sun, 12 Oct 2014 18:25:51 +0200 From: Yamagi Burmeister To: rodrigc@FreeBSD.org Subject: Re: Enabling VIMAGE by default for FreeBSD 11? Message-Id: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> In-Reply-To: References: X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 16:26:13 -0000 Hello, it's been a while since I tested VIMAGE, but at the last time somewhere in 10-CURRENT some UMA memory leaks were left when destroying vnets. They weren't showstoppers for most workloads, but pretty anoying... Have those been fixed? Regards, Yamagi On Sat, 11 Oct 2014 10:58:13 -0700 Craig Rodrigues wrote: > Hi, > > What action items are left to enable VIMAGE by default for FreeBSD 11? > > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. > > -- > Craig > _______________________________________________ > 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" -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 16:39:18 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CADC3884; Sun, 12 Oct 2014 16:39:18 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E7E1B9A; Sun, 12 Oct 2014 16:39:18 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C60AA25D3871; Sun, 12 Oct 2014 16:39:14 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id BE68EC77059; Sun, 12 Oct 2014 16:39:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id TV1S1_2Nz-Kn; Sun, 12 Oct 2014 16:39:12 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:9939:1d52:4fd1:db6c] (unknown [IPv6:fde9:577b:c1a9:4410:9939:1d52:4fd1:db6c]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0B5A5C77058; Sun, 12 Oct 2014 16:39:10 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: "Bjoern A. Zeeb" In-Reply-To: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> Date: Sun, 12 Oct 2014 16:38:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> To: Yamagi Burmeister X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , freebsd-virtualization@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 16:39:18 -0000 On 12 Oct 2014, at 16:25 , Yamagi Burmeister wrote: > Hello, > it's been a while since I tested VIMAGE, but at the last time = somewhere > in 10-CURRENT some UMA memory leaks were left when destroying vnets.=20= > They weren't showstoppers for most workloads, but pretty anoying... > Have those been fixed? No, an old perforce branch of mine had all but the last TCP ones fixed. = The code is still there. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 18:19:07 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F45C60B; Sun, 12 Oct 2014 18:19:07 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F73078F; Sun, 12 Oct 2014 18:19:06 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so5386377lbv.38 for ; Sun, 12 Oct 2014 11:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Iz/g02UBahml6Zro5OlZ6eWinLs6mAACAv5SZ7kExBY=; b=ML552fr5KeFuR9cxoFOkSvbMBm3yj19sGmTuuqDfCyv5bvG7bOmyB1HXuE6TdFNpao 59bKm7sXRkJ1q3R1ggrFwu6ammcYUHTKPST6u2waYgCmttJ8KjOtFQIPaDkR6XU6p+F4 eamGMoZF8cTvkQtLnBhEwBiUC1ozQxGH+KS7XVp4ncFdmkfyXuAGalbgN05jEvBr/Q2N +JAONub+9k8nRmhqKY/szJPGh8hVWBbeKmLFW7Uwbdw75AuOE0yzGHoihYkEpaRJK5wT 5kcSMIReq7KvbbK4FIOI8w6hJZgimT22PBu6PNtL9Pf3sn5vyuJtDhYR6p4SFoOy0FPG D8ww== MIME-Version: 1.0 X-Received: by 10.112.134.101 with SMTP id pj5mr18677030lbb.47.1413137944439; Sun, 12 Oct 2014 11:19:04 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Sun, 12 Oct 2014 11:19:04 -0700 (PDT) Received: by 10.112.131.66 with HTTP; Sun, 12 Oct 2014 11:19:04 -0700 (PDT) In-Reply-To: <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> Date: Sun, 12 Oct 2014 11:19:04 -0700 X-Google-Sender-Auth: R9wUGkoMF7wsEm2gDKpiDuYGbBo Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 18:19:07 -0000 On Oct 12, 2014 9:39 AM, "Bjoern A. Zeeb" wrote: > > No, an old perforce branch of mine had all but the last TCP ones fixed. The code is still there. > Can you provide a pointer to your Perforce branch? -- Craig From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 20:05:09 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D2C5906; Sun, 12 Oct 2014 20:05:09 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 468FA14B; Sun, 12 Oct 2014 20:05:08 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so7286100wgh.23 for ; Sun, 12 Oct 2014 13:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:from:date:to:cc:message-id; bh=KjDtT6A8FufmmTeZbeopSewaOm9stQITH9bnmaobN8s=; b=EdLYUkSOaTSQBI2mfcd+rrn1nKqlkar7ed4J2Plw3XcRyc2Gl5lGeMQtcDza0tb02Y +7+V48GCHkc3pYmAZT7WR9D3S+oI40TpDBwRuxiD2MseL+jGPAKpbdBS/JsGitttsTcG 635zbIhqb6zBASHhciBQP+zJHiB3hE6Ufv1k5qriAPntQ2Q1q233cijzZPAjMbDPLyyI hrWYRdmoTKS9dzpPqZKkDgwpumb8BAjm53rEJepOxSugUIJufjQSppDAaAfU3ixCyvNf aOcDabm0l5EaGr37p2dT79423MLM69j0JaOrf7owu/NEjCnj7UUnBgB4qWyfIMjrOPSo /DVw== X-Received: by 10.180.77.169 with SMTP id t9mr3322115wiw.58.1413144305553; Sun, 12 Oct 2014 13:05:05 -0700 (PDT) Received: from ?IPv6:2001:470:1f15:59b:4940:ce63:f97a:a6d7? ([2001:470:1f15:59b:4940:ce63:f97a:a6d7]) by mx.google.com with ESMTPSA id l10sm9857466wif.20.2014.10.12.13.05.04 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 13:05:05 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <822C5CED-1A0B-431A-B74B-CDEF3F8086F1@dataix.net> References: <822C5CED-1A0B-431A-B74B-CDEF3F8086F1@dataix.net> MIME-Version: 1.0 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Miguel Clara Date: Sun, 12 Oct 2014 20:44:29 +0100 To: Jason Hellenthal , Adrian Chadd Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 20:05:09 -0000 For me pf is working pretty nice on the host, it's only on the jails that it can creates all kinds of trouble , but on the host I've not seen issues so far, in both freebsd 9 and 10. Have not tested in current though. On 12 October 2014 12:28:06 WEST, Jason Hellenthal wrote: >Should also add here that for those using PF as a firewall that VIMAGE >enabled kernels don't play to well together.... Unless you like looking >at cores all day. > >-- > Jason Hellenthal > Mobile: +1 (616) 953-0176 > jhellenthal@DataIX.net > JJH48-ARIN > >On Oct 12, 2014, at 01:15, Adrian Chadd wrote: > >... is it enabled by default on pcbsd? > > >-a >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >_______________________________________________ >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" -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-arch@FreeBSD.ORG Sun Oct 12 20:15:49 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7F2EBFB; Sun, 12 Oct 2014 20:15:48 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEB8C236; Sun, 12 Oct 2014 20:15:47 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so5491287lbv.10 for ; Sun, 12 Oct 2014 13:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Fp1ks4Gl+ffEc/EOZiNyxds9uUWHnfiPJ9kCo8T9by0=; b=RCwjUKAIDjSPCu/qi4CdFX6VpW5fo9CTX42Ic3yS+S3g/qAxbvoz0+nVrSIxA6Ey8G aqbyczGTNRWlVt+ijZchpkppuvQNmSR5Z7CsS45Qr+r7m2dWAhWxVtRySV2l/UZqmys3 al+zWTeYBEI9f0qga8JBHveM7cNXIDsh5EbDgMUZ0hTcSXNMteW2/m9mK76q6naDuKiS WyVM13oYzupaxbmbYw2vhoJpHlYPzG8IgfbANTOhmPqW7DiHMDlpmBLT8mvF4WXUc3XY ImXyCpLB1Hz+1VMwnNpyp24nIB+v3PN2BiMfj6sUwyFOSpgqBZ/l/1rG7SkluxSFQDPj JMYA== MIME-Version: 1.0 X-Received: by 10.152.3.167 with SMTP id d7mr19410521lad.17.1413144945940; Sun, 12 Oct 2014 13:15:45 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Sun, 12 Oct 2014 13:15:45 -0700 (PDT) In-Reply-To: <543A7504.5090700@freebsd.org> References: <822C5CED-1A0B-431A-B74B-CDEF3F8086F1@dataix.net> <543A7504.5090700@freebsd.org> Date: Sun, 12 Oct 2014 13:15:45 -0700 X-Google-Sender-Auth: SKTMp6GZE4Dqu8ggKLvWR4bFRxY Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 20:15:49 -0000 On Sun, Oct 12, 2014 at 5:33 AM, Allan Jude wrote: > On 2014-10-12 07:28, Jason Hellenthal wrote: > > Should also add here that for those using PF as a firewall that VIMAGE > enabled kernels don't play to well together.... Unless you like looking at > cores all day. > > > > There have been patches to address this. I know Martin mm@freebsd.org > had something, I was talking to him about it at AsiaBSDCon this spring. > > pf patches for vnet have been committed to this branch: https://svnweb.freebsd.org/base/projects/pf/head/ Some of the patches have been merged to HEAD such as this: https://svnweb.freebsd.org/base?view=revision&revision=264689 -- Craig From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 01:08:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29CE1DAA; Mon, 13 Oct 2014 01:08:02 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D1ECD1AA; Mon, 13 Oct 2014 01:08:01 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8C44825D3A92; Mon, 13 Oct 2014 01:07:58 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A6085C7706D; Mon, 13 Oct 2014 01:07:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 4CNMJSQqcO71; Mon, 13 Oct 2014 01:07:56 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:5130:92a9:98c8:e33] (unknown [IPv6:fde9:577b:c1a9:4410:5130:92a9:98c8:e33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 52AF8C77057; Mon, 13 Oct 2014 01:07:55 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: "Bjoern A. Zeeb" In-Reply-To: Date: Mon, 13 Oct 2014 01:07:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 01:08:02 -0000 On 12 Oct 2014, at 18:19 , Craig Rodrigues wrote: > On Oct 12, 2014 9:39 AM, "Bjoern A. Zeeb" = > wrote: >>=20 >> No, an old perforce branch of mine had all but the last TCP ones = fixed. > The code is still there. >>=20 >=20 > Can you provide a pointer to your Perforce branch? //depot/user/bz/vimage/src/=85 Also if people are seriously thinking about virtualising pf we need to = import the openbsd/apple pf fix from a few years ago because otherwise = people in virtualised stacks with a /dev/pf can do ugly things. I = think it=92s been this one: = http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2010-3830 /bz =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 04:57:29 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38A5A764 for ; Mon, 13 Oct 2014 04:57:29 +0000 (UTC) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F374B1B for ; Mon, 13 Oct 2014 04:57:28 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.6 #37010) id <01PDOH07KRC00003PW@tmk.com> for freebsd-arch@freebsd.org; Mon, 13 Oct 2014 00:57:10 -0400 (EDT) Date: Mon, 13 Oct 2014 00:56:09 -0400 (EDT) From: Terry Kennedy Subject: [rfc] Add boot-time warning messages to PAE kernels To: freebsd-arch@freebsd.org Message-id: <01PDOI9M51BK0003PW@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 04:57:29 -0000 [Inspired by an unrelated email conversation with jhb@] On the FreeBSD forums and also elsewhere, people frequently ask questions about enabling PAE. Generally, this is because they don't know that amd64 kernels will run on their hardware. I initially proposed a static warning message, similar to the ones that happen when a kernel is built with INVARIANTS or WITNESS, with some sort of warning that "You probably don't want to do this". On thinking it over and discussing with jhb@, I think there are three scenarios that could be addressed: 1) Boot PAE kernel on any amd64-capable processor - display a warning message stating that the user should consider using the amd64 kernel instead. 2) Boot PAE kernel on any processor - display a warning message that driver support is limited on PAE kernels and that they receive less testing than non-PAE kernels. 3) [Possibly] Boot i386 kernel on amd64-capable system w/ > 4GB of RAM - display an informational message that the user should consider using the amd64 kernel instead. This way, anyone that still needs to run a PAE kernel can, but the users who choose it by accident or mistake will be guided to the amd64 kernel. Adding a similar message to i386 kernels on amd64-capable hardware w/ more than 4GB of RAM will likewise direct those users toward a more optimal kernel. I mention this because I was having a conversation with a user who was trying to get ZFS going but "ran out of memory" on a 12GB system due to using the i386 kernel. All of this information (processor capability flags and memory size) is available early enough in the boot process that the messages can be displayed near the beginning of the kernel messages. Non-amd64-capable systems that have > 4GB were always a small subset of the population, and that hardware has aged enough that much of it is no longer used in its original role as business servers. These are pre-Socket 604 systems, for example. amd64-capable hardware has been available for more than 10 years from both AMD and Intel at this point. Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 05:35:31 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72812E0B; Mon, 13 Oct 2014 05:35:31 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F99FE6D; Mon, 13 Oct 2014 05:35:30 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-237-201.lns20.per1.internode.on.net [121.45.237.201]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9D5ZFMZ023499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 12 Oct 2014 22:35:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <543B648D.6020403@freebsd.org> Date: Mon, 13 Oct 2014 13:35:09 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: wishmaster , "Alexander V. Chernikov" Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <1413092963.907920156.b727jzia@frv34.fwdcdn.com> In-Reply-To: <1413092963.907920156.b727jzia@frv34.fwdcdn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 05:35:31 -0000 On 10/12/14, 1:55 PM, wishmaster wrote: > > > --- Original message --- > From: "Alexander V. Chernikov" > Date: 11 October 2014, 23:20:39 > > > >> On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: >> >>> Hi, >>> >>> What action items are left to enable VIMAGE by default for FreeBSD 11? >> Are there any tests results showing performance implications on different network-related workloads? the last time we teste things vnet made things faster. if you spread 100 sessions over N vnets and had 100 sessions on one system, then there are 1/N as many locking collisions as each vnet is its own locking domain. Julian From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 11:47:40 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AABD9999; Mon, 13 Oct 2014 11:47:40 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67FE2870; Mon, 13 Oct 2014 11:47:40 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xda6X-000IyI-LG; Mon, 13 Oct 2014 11:31:41 +0400 Message-ID: <543BBB83.6010309@FreeBSD.org> Date: Mon, 13 Oct 2014 15:46:11 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Julian Elischer , wishmaster Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <1413092963.907920156.b727jzia@frv34.fwdcdn.com> <543B648D.6020403@freebsd.org> In-Reply-To: <543B648D.6020403@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 11:47:40 -0000 On 13.10.2014 09:35, Julian Elischer wrote: > On 10/12/14, 1:55 PM, wishmaster wrote: >> >> --- Original message --- >> From: "Alexander V. Chernikov" >> Date: 11 October 2014, 23:20:39 >> >> >>> On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: >>> >>>> Hi, >>>> >>>> What action items are left to enable VIMAGE by default for FreeBSD 11? >>> Are there any tests results showing performance implications on >>> different network-related workloads? > > the last time we teste things vnet made things faster. > > if you spread 100 sessions over N vnets and had 100 sessions on one > system, > then there are 1/N as many locking collisions as each vnet is its own > locking domain. Sure. I'm mostly concerned about performance impact on non-virtualized workloads (e.g. web server or firewall workload types). > > Julian > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 15:01:58 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D2D56DD for ; Mon, 13 Oct 2014 15:01:58 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 016A8F0B for ; Mon, 13 Oct 2014 15:01:57 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xdh8B-000OHF-1N; Mon, 13 Oct 2014 15:01:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9DF1nib044214; Mon, 13 Oct 2014 09:01:49 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/T/3lJpC2pFPBgwKswEclW X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [rfc] Add boot-time warning messages to PAE kernels From: Ian Lepore To: Terry Kennedy In-Reply-To: <01PDOI9M51BK0003PW@tmk.com> References: <01PDOI9M51BK0003PW@tmk.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Oct 2014 09:01:47 -0600 Message-ID: <1413212507.12052.323.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:01:58 -0000 On Mon, 2014-10-13 at 00:56 -0400, Terry Kennedy wrote: > [Inspired by an unrelated email conversation with jhb@] > > On the FreeBSD forums and also elsewhere, people frequently ask questions > about enabling PAE. Generally, this is because they don't know that amd64 > kernels will run on their hardware. > > I initially proposed a static warning message, similar to the ones that > happen when a kernel is built with INVARIANTS or WITNESS, with some sort > of warning that "You probably don't want to do this". On thinking it over > and discussing with jhb@, I think there are three scenarios that could be > addressed: > > 1) Boot PAE kernel on any amd64-capable processor - display a warning > message stating that the user should consider using the amd64 kernel > instead. > > 2) Boot PAE kernel on any processor - display a warning message that > driver support is limited on PAE kernels and that they receive less > testing than non-PAE kernels. > > 3) [Possibly] Boot i386 kernel on amd64-capable system w/ > 4GB of RAM - > display an informational message that the user should consider using > the amd64 kernel instead. > > This way, anyone that still needs to run a PAE kernel can, but the users > who choose it by accident or mistake will be guided to the amd64 kernel. > Adding a similar message to i386 kernels on amd64-capable hardware w/ more > than 4GB of RAM will likewise direct those users toward a more optimal > kernel. I mention this because I was having a conversation with a user who > was trying to get ZFS going but "ran out of memory" on a 12GB system due > to using the i386 kernel. > > All of this information (processor capability flags and memory size) > is available early enough in the boot process that the messages can be > displayed near the beginning of the kernel messages. > > Non-amd64-capable systems that have > 4GB were always a small subset of > the population, and that hardware has aged enough that much of it is no > longer used in its original role as business servers. These are pre-Socket > 604 systems, for example. amd64-capable hardware has been available for > more than 10 years from both AMD and Intel at this point. > > Terry Kennedy http://www.tmk.com > terry@tmk.com New York, NY USA No no no no no. People who are smart enough to build themselves a different kernel should not get their noses rubbed in your idea of what's right every time they boot. I run a PAE kernel for my own reasons, and they are good reasons for me regardless of what you think about it. And can we finally lose the mythology that PAE is somehow experimental or inadequate? I've never encountered a driver that doesn't work with PAE (I'm sure they exist, but again, people smart enough to build a custom kernel should be smart enough to deal with testing it with the devices they use). -- Ian From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 15:16:20 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53C9B972 for ; Mon, 13 Oct 2014 15:16:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D56688 for ; Mon, 13 Oct 2014 15:16:20 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2341AB939; Mon, 13 Oct 2014 11:16:19 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: [rfc] Add boot-time warning messages to PAE kernels Date: Mon, 13 Oct 2014 10:57:23 -0400 Message-ID: <5523023.h2nJCgOPoX@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <01PDOI9M51BK0003PW@tmk.com> References: <01PDOI9M51BK0003PW@tmk.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 13 Oct 2014 11:16:19 -0400 (EDT) Cc: Terry Kennedy X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:16:20 -0000 On Monday, October 13, 2014 12:56:09 AM Terry Kennedy wrote: > [Inspired by an unrelated email conversation with jhb@] > > On the FreeBSD forums and also elsewhere, people frequently ask questions > about enabling PAE. Generally, this is because they don't know that amd64 > kernels will run on their hardware. > > I initially proposed a static warning message, similar to the ones that > happen when a kernel is built with INVARIANTS or WITNESS, with some sort > of warning that "You probably don't want to do this". On thinking it over > and discussing with jhb@, I think there are three scenarios that could be > addressed: > > 1) Boot PAE kernel on any amd64-capable processor - display a warning > message stating that the user should consider using the amd64 kernel > instead. > > 2) Boot PAE kernel on any processor - display a warning message that > driver support is limited on PAE kernels and that they receive less > testing than non-PAE kernels. > > 3) [Possibly] Boot i386 kernel on amd64-capable system w/ > 4GB of RAM - > display an informational message that the user should consider using > the amd64 kernel instead. > > This way, anyone that still needs to run a PAE kernel can, but the users > who choose it by accident or mistake will be guided to the amd64 kernel. > Adding a similar message to i386 kernels on amd64-capable hardware w/ more > than 4GB of RAM will likewise direct those users toward a more optimal > kernel. I mention this because I was having a conversation with a user who > was trying to get ZFS going but "ran out of memory" on a 12GB system due > to using the i386 kernel. > > All of this information (processor capability flags and memory size) > is available early enough in the boot process that the messages can be > displayed near the beginning of the kernel messages. > > Non-amd64-capable systems that have > 4GB were always a small subset of > the population, and that hardware has aged enough that much of it is no > longer used in its original role as business servers. These are pre-Socket > 604 systems, for example. amd64-capable hardware has been available for > more than 10 years from both AMD and Intel at this point. I actually think we should consider doing this for all i386 kernels regardless of the 4GB of RAM check. Something like this: diff --git a/sys/i386/i386/machdep.c b/sys/i386/i386/machdep.c index 9d98f0e..6fbf419 100644 --- a/sys/i386/i386/machdep.c +++ b/sys/i386/i386/machdep.c @@ -4067,3 +4067,17 @@ outb_(u_short port, u_char data) } #endif /* KDB */ + +static void +warn64(void *arg __unused) +{ + + if ((cpu_vendor_id == CPU_VENDOR_INTEL || + cpu_vendor_id == CPU_VENDOR_AMD || + cpu_vendor_id == CPU_VENDOR_CENTAUR) && + amd_feature & AMDID_LM) + printf("WARNING: 64-bit capable CPU, consider running " + "FreeBSD/amd64 instead.\n"); +} +SYSINIT(warn64, SI_SUB_COPYRIGHT, SI_ORDER_THIRD + 3, warn64, NULL); +SYSINIT(warn64_2, SI_SUB_LAST, SI_ORDER_THIRD + 3, warn64, NULL); -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 15:27:49 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E095429 for ; Mon, 13 Oct 2014 15:27:49 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB9C1E1 for ; Mon, 13 Oct 2014 15:27:48 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id ey11so6060447pad.27 for ; Mon, 13 Oct 2014 08:27:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=EzQEjJycRTofBeRwB+n2wzDF2dxbYoPHh4D6zXPy1wk=; b=doqgWfCce4ncLMrEt+HgIgclDPGDn/HRNnkjrI8J9DBv6jXNSePYB2nMNnKAGwiCI5 K0PYCl/5XO/DzOQ5sjaMYDaxJLr8N/wMzZRhft++ZUZ/zc7uSJdQG9Qz0g2XQuMZ2KBl tiNWSYBbP63mTbh9p86VNTzk3amf5NXkZPRDF/9WOQJjZ0KzxJkxRa9p/Y7EzKsmON19 fNlBgUz/AGHSKi7yWADV5TEcqbXnu5TuvQ/7mO/1bkvv/zp+Idu34C+PDttTZYXLwFYN jNAB1JZjX94yM3b5NdyZEkecltYSEE41ULSy0LOvXtw2gxaSKrWrh5RZ1c2pr4qNYBU7 pJ1Q== X-Gm-Message-State: ALoCoQlyKw+rS2zDBgODbI73vbVGzkRqW19pADPZI7UVP7XnB6mnpa1+Z1ubbWGuvj6UaJAmKBx3 X-Received: by 10.68.178.97 with SMTP id cx1mr24448234pbc.25.1413214067792; Mon, 13 Oct 2014 08:27:47 -0700 (PDT) Received: from [10.64.26.87] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id k11sm7770525pbq.0.2014.10.13.08.27.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 08:27:46 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_620F4880-9C5B-47F5-ADD4-5AF82A7891A0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [rfc] Add boot-time warning messages to PAE kernels From: Warner Losh In-Reply-To: <5523023.h2nJCgOPoX@ralph.baldwin.cx> Date: Mon, 13 Oct 2014 09:27:44 -0600 Message-Id: References: <01PDOI9M51BK0003PW@tmk.com> <5523023.h2nJCgOPoX@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: Terry Kennedy , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:27:49 -0000 --Apple-Mail=_620F4880-9C5B-47F5-ADD4-5AF82A7891A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 13, 2014, at 8:57 AM, John Baldwin wrote: > On Monday, October 13, 2014 12:56:09 AM Terry Kennedy wrote: >> [Inspired by an unrelated email conversation with jhb@] >>=20 >> On the FreeBSD forums and also elsewhere, people frequently ask = questions >> about enabling PAE. Generally, this is because they don't know that = amd64 >> kernels will run on their hardware. >>=20 >> I initially proposed a static warning message, similar to the ones = that >> happen when a kernel is built with INVARIANTS or WITNESS, with some = sort >> of warning that "You probably don't want to do this". On thinking it = over >> and discussing with jhb@, I think there are three scenarios that = could be >> addressed: >>=20 >> 1) Boot PAE kernel on any amd64-capable processor - display a = warning >> message stating that the user should consider using the amd64 = kernel >> instead. >>=20 >> 2) Boot PAE kernel on any processor - display a warning message that >> driver support is limited on PAE kernels and that they receive = less >> testing than non-PAE kernels. >>=20 >> 3) [Possibly] Boot i386 kernel on amd64-capable system w/ > 4GB of = RAM - >> display an informational message that the user should consider = using >> the amd64 kernel instead. >>=20 >> This way, anyone that still needs to run a PAE kernel can, but the = users >> who choose it by accident or mistake will be guided to the amd64 = kernel. >> Adding a similar message to i386 kernels on amd64-capable hardware w/ = more >> than 4GB of RAM will likewise direct those users toward a more = optimal >> kernel. I mention this because I was having a conversation with a = user who >> was trying to get ZFS going but "ran out of memory" on a 12GB system = due >> to using the i386 kernel. >>=20 >> All of this information (processor capability flags and memory size) >> is available early enough in the boot process that the messages can = be >> displayed near the beginning of the kernel messages. >>=20 >> Non-amd64-capable systems that have > 4GB were always a small subset = of >> the population, and that hardware has aged enough that much of it is = no >> longer used in its original role as business servers. These are = pre-Socket >> 604 systems, for example. amd64-capable hardware has been available = for >> more than 10 years from both AMD and Intel at this point. >=20 > I actually think we should consider doing this for all i386 kernels = regardless=20 > of the 4GB of RAM check. Something like this: >=20 > diff --git a/sys/i386/i386/machdep.c b/sys/i386/i386/machdep.c > index 9d98f0e..6fbf419 100644 > --- a/sys/i386/i386/machdep.c > +++ b/sys/i386/i386/machdep.c > @@ -4067,3 +4067,17 @@ outb_(u_short port, u_char data) > } >=20 > #endif /* KDB */ > + > +static void > +warn64(void *arg __unused) > +{ > + > + if ((cpu_vendor_id =3D=3D CPU_VENDOR_INTEL || > + cpu_vendor_id =3D=3D CPU_VENDOR_AMD || > + cpu_vendor_id =3D=3D CPU_VENDOR_CENTAUR) && > + amd_feature & AMDID_LM) > + printf("WARNING: 64-bit capable CPU, consider running " > + "FreeBSD/amd64 instead.\n"); > +} > +SYSINIT(warn64, SI_SUB_COPYRIGHT, SI_ORDER_THIRD + 3, warn64, NULL); > +SYSINIT(warn64_2, SI_SUB_LAST, SI_ORDER_THIRD + 3, warn64, NULL); Where=92s warn64_2 defined :) I=92d add a && !stfu_warn64 in there somewhere that=92s set as a = tunable. It is a good seat belt for the newbie running the wrong thing (though maybe 7 years too late), but experienced users may wish to stifle it for = organizational reasons. Some organizations have a no warning policy where they have to do something about the warnings, even if there=92s nothing to do. = Providing an easy way to STFU the warning would allow them to run with a stock = kernel or perhaps (if done as a config option instead) a custom kernel config. Warner --Apple-Mail=_620F4880-9C5B-47F5-ADD4-5AF82A7891A0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUO+9wAAoJEGwc0Sh9sBEAIj0P/0noRLNVVIA3MjATgM4griDQ NuCOtocflpisAiluWvmcKbPoaeen22sFKxoqaY2cYz4T4szhCdDEZe63vShlZIpW N1QlnArfP4gu3Aijcf6oxgTkqEnzHn0PZmXUopS/60dqSLWft8Q8ZzBOX7o+fP1s gvRmL5vaf8W5w2yzOEFVCIbZNk5rykKb1cNKqmxU8GYuAQWXWniJPRm9J+9NftFG sKKqDJHo+Sjj4NW7MwuhQDktV6XhKuLvoDSi4UgYGb87JvFV3EOJmitjaebGMoNI Yx80Ch1QJ4ki9mLFTmBWak9JjJ1MbuNO/nd8B1vS8yOZrmJq38ecu3s9QZD9Y2QU zmTxJPxMM+vovQtM7dCD5446xAf5+TdHJVihVUuQ5Q8MZ07IsUc1Z/BB8u3kHj15 rNoIxA+jjqcHain8ub9SrbUtsSb8xswRXuSZL8c7yAhyoOM+pGmzCKCZmDHYxZdN P6R+HHzLJgR4LAIlfqs14W3S7wyBPmgbmG6lXFu3qU3LoqxMTRphKG5SQqN94AMa nENNmVcGaP+a6PsSXPybt4XLB9JWezBFFGiizt6Jg3ncHhpy1nPhV8/DVwVngDec BgB2X0DDRtPHyVrwh7xsw+WOxUmSAHdHWca1bL23ecvLYAH2VsszS9vMPDzX4ho2 X95akGqpYYWhWJ9oCCAA =Luaj -----END PGP SIGNATURE----- --Apple-Mail=_620F4880-9C5B-47F5-ADD4-5AF82A7891A0-- From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 15:35:16 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1792834; Mon, 13 Oct 2014 15:35:16 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60C402E4; Mon, 13 Oct 2014 15:35:15 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XdheU-000Hrr-Qb; Mon, 13 Oct 2014 15:35:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9DFZDvZ044271; Mon, 13 Oct 2014 09:35:13 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+sgQZf+CqlfROLcpOQ9r4t X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [rfc] Add boot-time warning messages to PAE kernels From: Ian Lepore To: Warner Losh In-Reply-To: References: <01PDOI9M51BK0003PW@tmk.com> <5523023.h2nJCgOPoX@ralph.baldwin.cx> Content-Type: text/plain; charset="iso-8859-13" Date: Mon, 13 Oct 2014 09:35:13 -0600 Message-ID: <1413214513.12052.327.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s9DFZDvZ044271 Cc: Terry Kennedy , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:35:16 -0000 On Mon, 2014-10-13 at 09:27 -0600, Warner Losh wrote: > On Oct 13, 2014, at 8:57 AM, John Baldwin wrote: >=20 > > On Monday, October 13, 2014 12:56:09 AM Terry Kennedy wrote: > >> [Inspired by an unrelated email conversation with jhb@] > >>=20 > >> On the FreeBSD forums and also elsewhere, people frequently ask que= stions > >> about enabling PAE. Generally, this is because they don't know that = amd64 > >> kernels will run on their hardware. > >>=20 > >> I initially proposed a static warning message, similar to the ones = that > >> happen when a kernel is built with INVARIANTS or WITNESS, with some = sort > >> of warning that "You probably don't want to do this". On thinking it= over > >> and discussing with jhb@, I think there are three scenarios that cou= ld be > >> addressed: > >>=20 > >> 1) Boot PAE kernel on any amd64-capable processor - display a warni= ng > >> message stating that the user should consider using the amd64 ke= rnel > >> instead. > >>=20 > >> 2) Boot PAE kernel on any processor - display a warning message tha= t > >> driver support is limited on PAE kernels and that they receive l= ess > >> testing than non-PAE kernels. > >>=20 > >> 3) [Possibly] Boot i386 kernel on amd64-capable system w/ > 4GB of = RAM - > >> display an informational message that the user should consider u= sing > >> the amd64 kernel instead. > >>=20 > >> This way, anyone that still needs to run a PAE kernel can, but the = users > >> who choose it by accident or mistake will be guided to the amd64 ker= nel. > >> Adding a similar message to i386 kernels on amd64-capable hardware w= / more > >> than 4GB of RAM will likewise direct those users toward a more optim= al > >> kernel. I mention this because I was having a conversation with a us= er who > >> was trying to get ZFS going but "ran out of memory" on a 12GB system= due > >> to using the i386 kernel. > >>=20 > >> All of this information (processor capability flags and memory size= ) > >> is available early enough in the boot process that the messages can = be > >> displayed near the beginning of the kernel messages. > >>=20 > >> Non-amd64-capable systems that have > 4GB were always a small subse= t of > >> the population, and that hardware has aged enough that much of it is= no > >> longer used in its original role as business servers. These are pre-= Socket > >> 604 systems, for example. amd64-capable hardware has been available = for > >> more than 10 years from both AMD and Intel at this point. > >=20 > > I actually think we should consider doing this for all i386 kernels r= egardless=20 > > of the 4GB of RAM check. Something like this: > >=20 > > diff --git a/sys/i386/i386/machdep.c b/sys/i386/i386/machdep.c > > index 9d98f0e..6fbf419 100644 > > --- a/sys/i386/i386/machdep.c > > +++ b/sys/i386/i386/machdep.c > > @@ -4067,3 +4067,17 @@ outb_(u_short port, u_char data) > > } > >=20 > > #endif /* KDB */ > > + > > +static void > > +warn64(void *arg __unused) > > +{ > > + > > + if ((cpu_vendor_id =3D=3D CPU_VENDOR_INTEL || > > + cpu_vendor_id =3D=3D CPU_VENDOR_AMD || > > + cpu_vendor_id =3D=3D CPU_VENDOR_CENTAUR) && > > + amd_feature & AMDID_LM) > > + printf("WARNING: 64-bit capable CPU, consider running " > > + "FreeBSD/amd64 instead.\n"); > > +} > > +SYSINIT(warn64, SI_SUB_COPYRIGHT, SI_ORDER_THIRD + 3, warn64, NULL); > > +SYSINIT(warn64_2, SI_SUB_LAST, SI_ORDER_THIRD + 3, warn64, NULL); >=20 > Where=FFs warn64_2 defined :) >=20 > I=FFd add a && !stfu_warn64 in there somewhere that=FFs set as a tunabl= e. It > is a good seat belt for the newbie running the wrong thing (though mayb= e > 7 years too late), but experienced users may wish to stifle it for orga= nizational > reasons. Some organizations have a no warning policy where they have t= o > do something about the warnings, even if there=FFs nothing to do. Provi= ding > an easy way to STFU the warning would allow them to run with a stock ke= rnel > or perhaps (if done as a config option instead) a custom kernel config. >=20 > Warner Inded, if this (anti-)feature goes in, we need an option to squelch the warning, preferably a compile-time option. We've got customers who think it's their job to spelunk through logs and raise a fuss about things they've never seen before or don't understand. That generates complaints to support reps who complain to managers who don't understand any of it except that a customer is complaining and insist that "something be done". If we must be saddled with "You don't know what you're doing" warnings, we have to at least be able to shut them up when it turns out we do know what we're doing. -- Ian From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 15:35:39 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 157DA8E6; Mon, 13 Oct 2014 15:35:39 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88F292F2; Mon, 13 Oct 2014 15:35:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9DFZTkA067284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 18:35:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9DFZTkA067284 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9DFZTkE067275; Mon, 13 Oct 2014 18:35:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Oct 2014 18:35:29 +0300 From: Konstantin Belousov To: Ian Lepore Subject: Re: [rfc] Add boot-time warning messages to PAE kernels Message-ID: <20141013153529.GP2153@kib.kiev.ua> References: <01PDOI9M51BK0003PW@tmk.com> <1413212507.12052.323.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1413212507.12052.323.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Terry Kennedy , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:35:39 -0000 On Mon, Oct 13, 2014 at 09:01:47AM -0600, Ian Lepore wrote: > On Mon, 2014-10-13 at 00:56 -0400, Terry Kennedy wrote: > > [Inspired by an unrelated email conversation with jhb@] > > > > On the FreeBSD forums and also elsewhere, people frequently ask questions > > about enabling PAE. Generally, this is because they don't know that amd64 > > kernels will run on their hardware. > > > > I initially proposed a static warning message, similar to the ones that > > happen when a kernel is built with INVARIANTS or WITNESS, with some sort > > of warning that "You probably don't want to do this". On thinking it over > > and discussing with jhb@, I think there are three scenarios that could be > > addressed: > > > > 1) Boot PAE kernel on any amd64-capable processor - display a warning > > message stating that the user should consider using the amd64 kernel > > instead. > > > > 2) Boot PAE kernel on any processor - display a warning message that > > driver support is limited on PAE kernels and that they receive less > > testing than non-PAE kernels. > > > > 3) [Possibly] Boot i386 kernel on amd64-capable system w/ > 4GB of RAM - > > display an informational message that the user should consider using > > the amd64 kernel instead. > > > > This way, anyone that still needs to run a PAE kernel can, but the users > > who choose it by accident or mistake will be guided to the amd64 kernel. > > Adding a similar message to i386 kernels on amd64-capable hardware w/ more > > than 4GB of RAM will likewise direct those users toward a more optimal > > kernel. I mention this because I was having a conversation with a user who > > was trying to get ZFS going but "ran out of memory" on a 12GB system due > > to using the i386 kernel. > > > > All of this information (processor capability flags and memory size) > > is available early enough in the boot process that the messages can be > > displayed near the beginning of the kernel messages. > > > > Non-amd64-capable systems that have > 4GB were always a small subset of > > the population, and that hardware has aged enough that much of it is no > > longer used in its original role as business servers. These are pre-Socket > > 604 systems, for example. amd64-capable hardware has been available for > > more than 10 years from both AMD and Intel at this point. > > > > Terry Kennedy http://www.tmk.com > > terry@tmk.com New York, NY USA > > No no no no no. People who are smart enough to build themselves a > different kernel should not get their noses rubbed in your idea of > what's right every time they boot. I run a PAE kernel for my own > reasons, and they are good reasons for me regardless of what you think > about it. I fully agree. Usually Unix kernels are silent. Starting to lecture users what to do is not very smart. PAE is the way to get NX bit on 32bit kernels. > > And can we finally lose the mythology that PAE is somehow experimental > or inadequate? I've never encountered a driver that doesn't work with > PAE (I'm sure they exist, but again, people smart enough to build a > custom kernel should be smart enough to deal with testing it with the > devices they use). The real issue with PAE is that auto-tuning easily makes non-working configuration due to small KVA (1 or 2 GB) comparing with the available physical RAM installed on the machine. It is more or less fine for 4GB machine, but AFAIR, is on the edge for 8GB, and breaks afterward. Lowering the user/kernel VA split helps somewhat. The solution for PAE issues is to implement separate address space for kernel. It would add some overhead on each mode switch, but this is the cost of being able to run what you need. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 20:03:53 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDF5FC97; Mon, 13 Oct 2014 20:03:53 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E16994E; Mon, 13 Oct 2014 20:03:53 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s9DK3j82024531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Oct 2014 14:03:45 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s9DK3jKQ024528; Mon, 13 Oct 2014 14:03:45 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 13 Oct 2014 14:03:45 -0600 (MDT) From: Warren Block To: John Baldwin Subject: Re: [rfc] Add boot-time warning messages to PAE kernels In-Reply-To: <5523023.h2nJCgOPoX@ralph.baldwin.cx> Message-ID: References: <01PDOI9M51BK0003PW@tmk.com> <5523023.h2nJCgOPoX@ralph.baldwin.cx> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 13 Oct 2014 14:03:45 -0600 (MDT) Cc: Terry Kennedy , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:03:53 -0000 On Mon, 13 Oct 2014, John Baldwin wrote: > I actually think we should consider doing this for all i386 kernels regardless > of the 4GB of RAM check. Something like this: > > diff --git a/sys/i386/i386/machdep.c b/sys/i386/i386/machdep.c > index 9d98f0e..6fbf419 100644 > --- a/sys/i386/i386/machdep.c > +++ b/sys/i386/i386/machdep.c > @@ -4067,3 +4067,17 @@ outb_(u_short port, u_char data) > } > > #endif /* KDB */ > + > +static void > +warn64(void *arg __unused) > +{ > + > + if ((cpu_vendor_id == CPU_VENDOR_INTEL || > + cpu_vendor_id == CPU_VENDOR_AMD || > + cpu_vendor_id == CPU_VENDOR_CENTAUR) && > + amd_feature & AMDID_LM) > + printf("WARNING: 64-bit capable CPU, consider running " > + "FreeBSD/amd64 instead.\n"); > +} > +SYSINIT(warn64, SI_SUB_COPYRIGHT, SI_ORDER_THIRD + 3, warn64, NULL); > +SYSINIT(warn64_2, SI_SUB_LAST, SI_ORDER_THIRD + 3, warn64, NULL); "WARNING" is a bit too strong. Personally, I'd prefer just a note of what is being missed: "Running in 32-bit mode on 64-bit CPU, FreeBSD/amd64 can provide increased performance and address space." Or something like that, the point is just to flip the comparison from what is lacking with i386 to what is better with amd64. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 22:02:35 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C10C3C3F for ; Mon, 13 Oct 2014 22:02:35 +0000 (UTC) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1707BD for ; Mon, 13 Oct 2014 22:02:34 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id q1so7451838lam.32 for ; Mon, 13 Oct 2014 15:02:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=9twvnwbKwvC61L+h8TRbjP2NqKDGkKl9Navlg56HZrU=; b=W4fA6oWdKTQuMCtHnOX1MKsJirw1TMau7K3xUkFgX/A6qD8OO9N9Q+Sy4EPe2DuiG6 rgw4/QT7gvgCZZbB01spiwNkYU5jHL1ICVZX+tN05RQlrFHvsyzZYowPpdEA8Fb10uOt AERDuXWedjXiaeSSOIAXpVy7Wp7SyHkUmiItWyJOM2DvSYR3iiTT5Yz+Tdqgt+QmL993 Pd52wJI2dXWlbIpvdUs/ZhGxWwQMaK4OkwEjnQBfPhg8af2KGDyglylAPWJ0Cb4npNs3 V3elk6Wc5B+dm4m4ZoDbeWG99/jB5SNteh5NjSBIesWlIkz1vCjeV9JXb/A2hAesWNiT UCFA== X-Gm-Message-State: ALoCoQmtWw96Im2PblPgrNs1z9jLb86FFRaOQ5PKIjF2Wwqi+R5g0vXY+Ukj6hzSwad2zzJHUjOE MIME-Version: 1.0 X-Received: by 10.112.201.138 with SMTP id ka10mr1344762lbc.20.1413237747203; Mon, 13 Oct 2014 15:02:27 -0700 (PDT) Received: by 10.25.23.85 with HTTP; Mon, 13 Oct 2014 15:02:27 -0700 (PDT) X-Originating-IP: [80.111.192.87] Date: Mon, 13 Oct 2014 23:02:27 +0100 Message-ID: Subject: PIE/PIC support on base From: David Carlier To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 22:02:35 -0000 Hi all, HardenedBSD plans to add PIE support on base in various place. These are B. Drewery suggestions : The _pic ones are not needed. The main lib file just needs INSTALL_PIC_ARCHIVE=yes. Modifying CFLAGS in every Makefile is not right, just add a USE_PIE or something to pull in common logic from share/mk. Also I know that, at least for a start, it wished to be applied in some few places, like tcpdump/traceroute, sendmail ... shells ... I thought about also casper/capsicum ... ntp ... jail Kind regards. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 14 06:20:25 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA05296A; Tue, 14 Oct 2014 06:20:24 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05B89C01; Tue, 14 Oct 2014 06:20:23 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id u10so7451351lbd.20 for ; Mon, 13 Oct 2014 23:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h/00Fi3hbfn+R5Vh5uhuiiNM3cR5WItIfJ800ZEMzuo=; b=lyZr0c7qG2IAmLY5iLBcLYQEom948wzLDISQcJXOGwRKu9vE8FdZRrKsv1uP2xt+h6 ePpTEW9amgduszHze3IsWdUqNm4/n0JzcXKhx2IF/JULHKlxlRz9EqQvEqXGS/XgCnXb 7h5xjGSKMKtnR34H69CivHaSnbI3hbsrMxHMjLjABVpRl9TfIHOlY/w4taid6gEx+6eZ 5IND8NplU+rFDTg67Rqw12oRD3Xr3xPLImh1pgOegwN8u+1pkMfIz4/7ZL7oRiZ3cIUf 3nI7FWXZrK/lCZcg4FCPEtRBpGFdVQ3XMSI4wv1QQC8pfdtiFyfDqAGhGfV3Utwvhv5i VNzg== MIME-Version: 1.0 X-Received: by 10.152.198.166 with SMTP id jd6mr2969525lac.81.1413267621921; Mon, 13 Oct 2014 23:20:21 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Mon, 13 Oct 2014 23:20:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Oct 2014 23:20:21 -0700 X-Google-Sender-Auth: VxNfv0aztQ3UC_s85B6VuD95lHI Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 06:20:25 -0000 On Sat, Oct 11, 2014 at 1:20 PM, Alexander V. Chernikov wrote: > > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > > > Hi, > > > > What action items are left to enable VIMAGE by default for FreeBSD 11? > Are there any tests results showing performance implications on different > network-related workloads? > > Alexander, Do you have a testbed where you could run a quick network test for non-virtualized workload: -> CURRENT without VIMAGE in kernel config -> CURRENT with VIMAGE in kernel config and provide some results ? -- Craig From owner-freebsd-arch@FreeBSD.ORG Tue Oct 14 09:45:08 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65C2E20F; Tue, 14 Oct 2014 09:45:08 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27C6A16A; Tue, 14 Oct 2014 09:45:08 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id fp1so7117858pdb.25 for ; Tue, 14 Oct 2014 02:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8UYiVK9NGcyN9eSODq9bZl1VNKe0w+VQ3TrvF7xHFE0=; b=dHMQFzEk9eK8VvwzpB2BoK93rkgE4PWsj/QCC5TfFLHKJGm9JkVkxgsJA+Zi3nCUvE z/t6G8nmkBjRRbKOZlmF1AIy8MuL2lfg0Yzaz6x477fhh9JTtoHhxTnIt2/XidL7eHAx yVqMQFo7TENzzrxihIOqaY/4nfwNtov7cbRy1HGVaC1FTltBJVjM4ZQK33BUBfekGRFJ UQYrQIb4/2dC96UAC+ackI4Y/bA2JM0VwOsHKAWl/Slvc0VKQl6xFLQNEGrICWbSRvq0 ThpEsfNgOzdiBRvb2W4RIBSjTVRoDOofeXNItqGi3l4UjvfWX2EL35I5CxAyQS66hH5h 649w== X-Received: by 10.68.248.40 with SMTP id yj8mr4333419pbc.58.1413279907665; Tue, 14 Oct 2014 02:45:07 -0700 (PDT) Received: from kmatoMacBook-Pro.local ([221.234.44.207]) by mx.google.com with ESMTPSA id ah2sm13795472pad.10.2014.10.14.02.45.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Oct 2014 02:45:07 -0700 (PDT) Message-ID: <543CF09D.8060307@gmail.com> Date: Tue, 14 Oct 2014 17:45:01 +0800 From: k simon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Bjoern A. Zeeb" , Yamagi Burmeister Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> In-Reply-To: <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Craig Rodrigues , FreeBSD Net , freebsd-virtualization@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:45:08 -0000 在 14-10-13 0:38, Bjoern A. Zeeb 写道: > > On 12 Oct 2014, at 16:25 , Yamagi Burmeister wrote: > >> Hello, >> it's been a while since I tested VIMAGE, but at the last time somewhere >> in 10-CURRENT some UMA memory leaks were left when destroying vnets. >> They weren't showstoppers for most workloads, but pretty anoying... >> Have those been fixed? > > No, an old perforce branch of mine had all but the last TCP ones fixed. The code is still there. > Did you mean it's still leaked with TCP services, eg. HTTP ? Simon From owner-freebsd-arch@FreeBSD.ORG Tue Oct 14 12:54:16 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA2A7568; Tue, 14 Oct 2014 12:54:16 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC38F9B6; Tue, 14 Oct 2014 12:54:15 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hi2so10033270wib.3 for ; Tue, 14 Oct 2014 05:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=moxtoELEe9C5snqJDIprkADyEPWkKD1WmGdefwrABMI=; b=hp5f75mvRhaaCFaVyhSX1l6VpxVHKJbRilkHZZok40Gdx9dxLbtGzVohS4KAmW9HrJ /YA92j0uR1+PTC8hPkSBNchfxOIHKypsmbC0OqbTmLI6PyYq/VfwJIK+gn/sy8DfDD3j M3eQ/AecaaTGpWDXfmJl5m64ynBi1ygx8ehMQvgSygv6WRBiKdpr6jSLamQV+wUu8EZ6 CNpBHwWCFm3OEbDCPY8u5mrGzDRWlkPRo16q+qWHw6Lf95TpK08IccpTP0cC2jSEwPtF IzwyaSYVGEuhJReFQczMXzezLt+p60OvXviLdJB8uhqG+96Eb3kH0tLIQRaAorZh1Hs+ aUww== X-Received: by 10.194.189.82 with SMTP id gg18mr2425936wjc.115.1413291254023; Tue, 14 Oct 2014 05:54:14 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.164.73 with HTTP; Tue, 14 Oct 2014 05:53:53 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 14 Oct 2014 14:53:53 +0200 X-Google-Sender-Auth: BFIwsLFn_vSaWlnJG5ku-1t8pRQ Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? To: Craig Rodrigues Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , "Alexander V. Chernikov" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:54:16 -0000 On Tue, Oct 14, 2014 at 8:20 AM, Craig Rodrigues wrote: > On Sat, Oct 11, 2014 at 1:20 PM, Alexander V. Chernikov > wrote: > > > > > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > > > > > Hi, > > > > > > What action items are left to enable VIMAGE by default for FreeBSD 11? > > Are there any tests results showing performance implications on different > > network-related workloads? > > > > > Alexander, > > Do you have a testbed where you could run a quick network test for > non-virtualized workload: > -> CURRENT without VIMAGE in kernel config > -> CURRENT with VIMAGE in kernel config > > and provide some results ? > I can use my forwarding/firewalling 10Giga lab for testing VIMAGE impact. Here are my ministat results (smallest packet size, value in packet-per-second, about 2000 flows). => I didn't see lot's of performance impact with VIMAGE option added in kernel. Forwarding difference : x forwarding.r272978-VIMAGE + forwarding.r272978 +----------------------------------------------------------------------+ |x +x x ++ + x x +| | |_____________________M__A________________________| | | |____________M____A________________| | +----------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 1929165 1998339 1963904 1966801.4 27506.256 + 5 1953943 2005868 1971503 1976523 19087.721 No difference proven at 95.0% confidence ipfw-statefull difference: x ipfw-statefull.r272978-VIMAGE + ipfw-statefull.r272978 +----------------------------------------------------------------------+ | x x * * + x+ +| ||_________MA__________| | | |_______________M_______A_______________________| | +----------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 1490042 1531750 1503590 1505175 16403.596 + 5 1502719 1589778 1517320 1529871.8 35404.181 No difference proven at 95.0% confidence pf-statefull difference: x pf-statefull.r272978-VIMAGE + pf-statefull.r272978 +----------------------------------------------------------------------+ |x + + x x *+ x +| | |__________________A____M_____________| | | |____________________A_M_________________| | +----------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 1315594 1341130 1334215 1331310 9769.922 + 5 1324108 1351078 1336257 1335044.2 10562.448 No difference proven at 95.0% confidence Regards From owner-freebsd-arch@FreeBSD.ORG Tue Oct 14 15:42:38 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46729506; Tue, 14 Oct 2014 15:42:38 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AED0FDD2; Tue, 14 Oct 2014 15:42:37 +0000 (UTC) X-AuditID: 12074425-f79e46d000002583-55-543d4465f49c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D7.DE.09603.5644D345; Tue, 14 Oct 2014 11:42:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9EFgSRv013806; Tue, 14 Oct 2014 11:42:29 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9EFgQ0f013460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Oct 2014 11:42:27 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9EFgPni016119; Tue, 14 Oct 2014 11:42:25 -0400 (EDT) Date: Tue, 14 Oct 2014 11:42:25 -0400 (EDT) From: Benjamin Kaduk To: =?ISO-8859-15?Q?Olivier_Cochard-Labb=E9?= Subject: Re: Enabling VIMAGE by default for FreeBSD 11? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixCmqrJvmYhti8J7TYvb0aUwWH3a0M1nM uvmVyeLZ1mYWBxaPaV9yPGZ8ms8SwBTFZZOSmpNZllqkb5fAlbH13F7mgu1sFZcmNbI0MK5l 7WLk5JAQMJGYtucgO4QtJnHh3nq2LkYuDiGB2UwSe5dfYIRwNjJK/GiYAtYhJHCISeJ/QwSE 3cAo0XSdD8RmEdCWOLtwCyOIzSagIjHzzUY2EFtEwEniy4957CCDmAXWM0o8b9wOlhAWMJeY 0v8SbCinQKDEgoOLwM7gFXCUWHntDtQZ3UwS628/AysSFdCRWL1/CgtEkaDEyZlPgGwOoKmB EjunaE5gFJyFJDMLIQMSZhbQlXiz6iAThK0tcf9mG9sCRpZVjLIpuVW6uYmZOcWpybrFyYl5 ealFuhZ6uZkleqkppZsYQYHO7qK6g3HCIaVDjAIcjEo8vAWRNiFCrIllxZW5hxglOZiURHlL jG1DhPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwKnAA5XhTEiurUovyYVLSHCxK4rybfvCFCAmk J5akZqemFqQWwWRlODiUJHgDnIEaBYtS01Mr0jJzShDSTBycIMN5gIZLgdTwFhck5hZnpkPk TzHqcrQ0ve1lEmLJy89LlRLnPeUEVCQAUpRRmgc3B5agXjGKA70lzCsDMooHmNzgJr0CWsIE tOR1sTXIkpJEhJRUA+NJbv9JC0o2dG86USdeuOrdE6sFUcHXLa1yzfhdCyWvLrtRbRJ5fp5z 2uYjstcbxMqFzT+Ja8dZMWx/md1rfzDkTuxXtsS3Wr3f1x31U1QWfK8wxcWk79GORr9JTwTX eyf+rImV6HhW0SL1TeSkSZtx8QbbOgn7/fZm7145n/qvGv9U+vdOSyWW4oxEQy3mouJEAB7O B8wrAwAA Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:42:38 -0000 On Tue, 14 Oct 2014, Olivier Cochard-Labb=E9 wrote: > I can use my forwarding/firewalling 10Giga lab for testing VIMAGE impact. > Here are my ministat results (smallest packet size, value in > packet-per-second, about 2000 flows). > =3D> I didn't see lot's of performance impact with VIMAGE option added in > kernel. Surely we would also want to test on some "low-end" networks as well ... we still have some 10/half networks here (luckily, nowhere that I frequent). -Ben From owner-freebsd-arch@FreeBSD.ORG Tue Oct 14 17:44:36 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE36B8A6 for ; Tue, 14 Oct 2014 17:44:36 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0DCCCD1 for ; Tue, 14 Oct 2014 17:44:36 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Xe69D-0006wG-Mk for freebsd-arch@freebsd.org; Tue, 14 Oct 2014 10:44:35 -0700 Date: Tue, 14 Oct 2014 10:44:35 -0700 (PDT) From: timp To: freebsd-arch@freebsd.org Message-ID: <1413308675697-5956783.post@n5.nabble.com> In-Reply-To: References: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 17:44:36 -0000 > Hi, > > What action items are left to enable VIMAGE by default for FreeBSD 11? > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. > -- > Craig That would be extremely great! There is a big hole in FreeBSD that already has a patch in such direction (os level virtualization). Another stuff which would be extremely useful in GENERIC then is RCTL and RACCT. I don't know why it's still not in GENERIC. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Enabling-VIMAGE-by-default-for-FreeBSD-11-tp5956040p5956783.html Sent from the freebsd-arch mailing list archive at Nabble.com. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 14 18:17:51 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B854F29D for ; Tue, 14 Oct 2014 18:17:51 +0000 (UTC) Received: from eastrmfepo202.cox.net (eastrmfepo202.cox.net [68.230.241.217]) by mx1.freebsd.org (Postfix) with ESMTP id 60F77F3 for ; Tue, 14 Oct 2014 18:17:50 +0000 (UTC) Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo202.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20141014181750.LIJL19010.eastrmfepo202.cox.net@eastrmimpo210> for ; Tue, 14 Oct 2014 14:17:50 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo210 with cox id 36Hp1p00K41obj4016Hp1S; Tue, 14 Oct 2014 14:17:49 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020205.543D68CE.0025,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=aZC/a2Ut c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=9cW_t1CCXrUA:10 a=f5xKl4ys9bwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=8nJEP1OIZ-IA:10 a=kviXuzpPAAAA:8 a=6I5d2MoRAAAA:8 a=M50rKQ7feiKH07HconkA:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <543D68BF.40707@cox.net> Date: Tue, 14 Oct 2014 14:17:35 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <1wLg1p00d2X408g01wLiUx> In-Reply-To: <1wLg1p00d2X408g01wLiUx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 18:17:51 -0000 Alexander V. Chernikov wrote: > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > >> Hi, >> >> What action items are left to enable VIMAGE by default for FreeBSD 11? > Are there any tests results showing performance implications on different network-related workloads? >> Not everyone uses bhyve, so VIMAGE is quite useful when using jails. >> >> -- >> Craig >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > i know little about chroot jails or 7 ring processor levels but let me ask rhetorically ... do you mean VIMAGE allows a jail to use an iface device for many IPs or even MAC? i thought that was already the case all cards can "listen" - it's only a headers trick per say. but do you mean a chroot can have access to an iface (which there are pkg for setting up if i remember)? but if a jail is allowed to use an iface why not allocate it - meaning: what is the purpose of middleman vimage connecting device to jail unless there is a strict filter inbetween (ie, strippign headers, or even controlling what iface/routes are alllowed)? i can't see what it's for, but much less making it mandatorily injected upon all jailsm, except maybe it may BREAK existing jails by allowing net access where there is NOT supposed to be any / assumed not to be any if they old programmers didn't want anyone compiling software who logged in: they'd insure there was no compiler. if they didn't want typing at a terminal: they'd take away the keyboard right? From owner-freebsd-arch@FreeBSD.ORG Tue Oct 14 18:30:04 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3182375E for ; Tue, 14 Oct 2014 18:30:04 +0000 (UTC) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by mx1.freebsd.org (Postfix) with ESMTP id D13C3229 for ; Tue, 14 Oct 2014 18:30:03 +0000 (UTC) Received: from eastrmimpo109 ([68.230.241.222]) by eastrmfepo201.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20141014183002.GPUQ31475.eastrmfepo201.cox.net@eastrmimpo109> for ; Tue, 14 Oct 2014 14:30:02 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo109 with cox id 36W11p00R41obj4016W2Vc; Tue, 14 Oct 2014 14:30:02 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020203.543D6BAA.0111,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=Y70mRGiN c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=9cW_t1CCXrUA:10 a=f5xKl4ys9bwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=8nJEP1OIZ-IA:10 a=kviXuzpPAAAA:8 a=6I5d2MoRAAAA:8 a=DZU4-uSclzPVfhO6uPUA:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <543D6B9B.2010505@cox.net> Date: Tue, 14 Oct 2014 14:29:47 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <1wLg1p00d2X408g01wLiUx> In-Reply-To: <1wLg1p00d2X408g01wLiUx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 18:30:04 -0000 Alexander V. Chernikov wrote: > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > >> Hi, >> >> What action items are left to enable VIMAGE by default for FreeBSD 11? well the next step is to make it a dependancy so that free bsd won't install without it, and to inject it in many binaries that insure it's "in use". like ssh ! the key is: 98 117C FE83 22EA B843 3E86 6486 4320 545E 1B2A FA1C just change anything you don't like in any jails being upgraded and tada you may get what's protected! can i have some? From owner-freebsd-arch@FreeBSD.ORG Tue Oct 14 19:45:13 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DF02E6C for ; Tue, 14 Oct 2014 19:45:13 +0000 (UTC) Received: from eastrmfepi101.cox.net (eastrmfepi101.cox.net [68.230.241.197]) by mx1.freebsd.org (Postfix) with ESMTP id B258AC84 for ; Tue, 14 Oct 2014 19:45:12 +0000 (UTC) Received: from eastrmimpo109 ([68.230.241.222]) by eastrmfepo202.cox.net (InterMail vM.8.01.05.15 201-2260-151-145-20131218) with ESMTP id <20141014174154.JXJL19010.eastrmfepo202.cox.net@eastrmimpo109> for ; Tue, 14 Oct 2014 13:41:54 -0400 Received: from [192.168.3.22] ([72.219.202.186]) by eastrmimpo109 with cox id 35ht1p00M41obj4015huJx; Tue, 14 Oct 2014 13:41:54 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020A.543D6062.014B,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=Y70mRGiN c=1 sm=1 a=k40gPPfQ5QH6qv5U/EJc3Q==:17 a=9cW_t1CCXrUA:10 a=f5xKl4ys9bwA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=IkcTkHD0fZMA:10 a=kviXuzpPAAAA:8 a=6I5d2MoRAAAA:8 a=7w0NfAVQfonXVPVrvakA:9 a=QEXdDO2ut3YA:10 a=SV7veod9ZcQA:10 a=k40gPPfQ5QH6qv5U/EJc3Q==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <543D6053.1010701@cox.net> Date: Tue, 14 Oct 2014 13:41:39 -0400 From: "John D. Hendrickson and Sara Darnell" Reply-To: johnandsara2@cox.net User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 CC: freebsd-arch@freebsd.org Subject: Re: [rfc] enumerating device / bus domain information References: <838B58B2-22D6-4AA4-97D5-62E87101F234@bsdimp.com> <1TyD1p0202X408g01TyFSr> In-Reply-To: <1TyD1p0202X408g01TyFSr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 19:45:13 -0000 John Baldwin wrote: > On Thursday, October 09, 2014 09:53:52 PM Warner Losh wrote: >> On Oct 8, 2014, at 5:12 PM, Adrian Chadd wrote: i probably shouldn't comment but if your talking about linux adding a NUMA infrastructure to bloat SMP and force all processors to talk through a single (albeit slower) channel. and i can't get my NUMA video driver to load so X acan see it, nor my soundcard. biatch. wow, that' not how i learned or used smp! (i see nothing towards running like mainframe, divisible banks loaned to logins each uploading it's own OS, and since i don't have one and am not a paid gov worker: i don't care either :) thanks keep up the good work have a good day ! From owner-freebsd-arch@FreeBSD.ORG Tue Oct 14 20:01:26 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40AB144A; Tue, 14 Oct 2014 20:01:26 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63C6CE53; Tue, 14 Oct 2014 20:01:25 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gi9so9076321lab.21 for ; Tue, 14 Oct 2014 13:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8tt9U4er2WE7Elavzxa0XSEoZRYieb2Qu/2tRGI0ULI=; b=JCSaUQSUGpht5kA+AQ3s49tM0q3Tm4pY8HA4f8ygkKps37sPbC5cCRgEfYIAcU4bON vzM3frRcYFcm7ArmfmuYcejjPuhTGfGcJyPokQTimSftlnPXWPr8+flh3ea/qAGHcZzH gOJ19KtC/VHyFg7cdFJNRjwpjtaCjE/OZu6+5WXB/r9inv65VcjPVX08rY7B4LVfAyK1 ibWCLjqUS8V7xpjnvJdbOa77fBene+h/dr61Xu5/Pee/41DcDjklO0DekT8BBDkg4X/v Tp7Pwoj3A4Q3bjtJqqP8cpt1wNRjcJpz2qddENUlrGUNnqmUniozEKO0ewRJLR/jATU7 lTKA== MIME-Version: 1.0 X-Received: by 10.152.7.7 with SMTP id f7mr7525494laa.57.1413316883303; Tue, 14 Oct 2014 13:01:23 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Tue, 14 Oct 2014 13:01:23 -0700 (PDT) In-Reply-To: <543D68BF.40707@cox.net> References: <543D68BF.40707@cox.net> Date: Tue, 14 Oct 2014 13:01:23 -0700 X-Google-Sender-Auth: NI0wY57cHsYYMZeRPLTEHjeB-yE Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: johnandsara2@cox.net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:01:26 -0000 On Tue, Oct 14, 2014 at 11:17 AM, John D. Hendrickson and Sara Darnell < johnandsara2@cox.net> wrote: > do you mean VIMAGE allows a jail to use an iface device for many IPs or > even MAC? i thought that was already the case all cards can "listen" - > it's only a headers trick per say. > > Search for VIMAGE here: https://www.freebsd.org/cgi/man.cgi?query=jail That gives a pretty good description of what VIMAGE and jails can do. -- Craig From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 01:15:37 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D892CC21; Wed, 15 Oct 2014 01:15:37 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03668216; Wed, 15 Oct 2014 01:15:36 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id q1so195630lam.4 for ; Tue, 14 Oct 2014 18:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gniovpb+640oYP5W/LcbtRBqtR9VtdhkpmPtjdPwTEU=; b=Rf3FZ1T8YUMZH+V51uRylLjjSNGAJcdH6tdYaiSEF+cAjcBSsyZUTL0l5GruJ/c5hA YB2AcH/IsYODLio6REdovx8uPRMYRlDQsinoDtjGeSH5E595fxHtGUOwbqdEdLBR+5U8 EiQbTEYtU/zIMN4BLmtL7MTYlDi/XT99LIt5YpD6IMrxc7N0kD1IWcy4Fl/PUmoF2lg0 T+bIpJV6mnBBMBm6ZHYlPtZpTcbpUVqPYYBiYhowWnkax/+tx0Jo0Saou9j7EjL9pZ4n xBLuKplcACY9Q8z5PPT1La5iOH+5prBZk7fJB6gRSgzt9JsTOJfElniae68n27YJWpoD 20Mw== MIME-Version: 1.0 X-Received: by 10.112.148.161 with SMTP id tt1mr8952985lbb.67.1413335734862; Tue, 14 Oct 2014 18:15:34 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Tue, 14 Oct 2014 18:15:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Oct 2014 18:15:34 -0700 X-Google-Sender-Auth: S6xN5BH9lpD1Wapt7RT8nXx-0ik Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , "Alexander V. Chernikov" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 01:15:38 -0000 On Tue, Oct 14, 2014 at 5:53 AM, Olivier Cochard-Labb=E9 wrote: > > I can use my forwarding/firewalling 10Giga lab for testing VIMAGE impact. > > Thank you for doing the test and providing the results. You put some good work into making those graphs and explaining the results! -- Craig From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 06:10:35 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6236ED11 for ; Wed, 15 Oct 2014 06:10:35 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E92B815E for ; Wed, 15 Oct 2014 06:10:34 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id d1so11918586wiv.8 for ; Tue, 14 Oct 2014 23:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=h/JcgTTaCKYG3S0hs1X4jmTdALhtpgqPKT1jO0PIpC0=; b=kTyypTuPxUXaKpOavozNnBx9IvFwgZh44DYQwL/+y++pk5kt3uYQj3N6NOu3HLUMUk 9tDs1FE7YiPT/JoXo7xYQku1jrE+QkEGdrOvT75OEkLgb+ssaXdKkYjIGzfAJ0JGnYII PlehrrqqbmU8tcSW4EflvbpsGEEX0JjqaQZqlqUeynQaq8/FfG54SW3wS2a9KlxmmVMB L0HGyQd75fXYnU80ruvUwj/e/bVa7Iabf3S2hIW/yK7+LaI7Zb4olDxKkKrP0VbVGdmt NhoBlBwbNLz2cBgU2yVDbBnyr7Ogvy1AIzp44hhMe2OmMbnp/DfE/qpKgLekvj2qZ2mZ Bo9Q== X-Received: by 10.180.188.229 with SMTP id gd5mr10119973wic.25.1413353433107; Tue, 14 Oct 2014 23:10:33 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id xm4sm18047854wib.9.2014.10.14.23.10.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Oct 2014 23:10:31 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 15 Oct 2014 08:10:29 +0200 From: Baptiste Daroussin To: David Carlier Subject: Re: PIE/PIC support on base Message-ID: <20141015061029.GO48641@ivaldir.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DITGHUV3p5DjDsXt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 06:10:35 -0000 --DITGHUV3p5DjDsXt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 13, 2014 at 11:02:27PM +0100, David Carlier wrote: > Hi all, >=20 > HardenedBSD plans to add PIE support on base in various place. >=20 > These are B. Drewery suggestions : >=20 > The _pic ones are not needed. The main lib file just needs > INSTALL_PIC_ARCHIVE=3Dyes. >=20 > Modifying CFLAGS in every Makefile is not right, just add a USE_PIE or > something to pull in common logic from share/mk. >=20 > Also I know that, at least for a start, it wished to be applied in some f= ew > places, like tcpdump/traceroute, sendmail ... shells ... I thought about > also casper/capsicum ... ntp ... jail >=20 What would probably be interesting is to list binary by binary on which one= you do want to add the USE_PIE, and with rational explaining why. On some OS you often can see ssh(1) not being PIE while sshd(8) have PIE. I think cherry-picking what should be PIE is the right regards, Bapt --DITGHUV3p5DjDsXt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQ+D9UACgkQ8kTtMUmk6Ez50QCfTXKsrIio1tjJNlq9HB3IHzA9 LaIAniLhqLGfVyvOC+1vaMYzxXXEy+rn =iS6c -----END PGP SIGNATURE----- --DITGHUV3p5DjDsXt-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 07:37:12 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85A8D298 for ; Wed, 15 Oct 2014 07:37:12 +0000 (UTC) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E186BEA for ; Wed, 15 Oct 2014 07:37:11 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.6 #37010) id <01PDRGCXWT4G000821@tmk.com> for freebsd-arch@freebsd.org; Wed, 15 Oct 2014 03:36:53 -0400 (EDT) Date: Wed, 15 Oct 2014 03:35:45 -0400 (EDT) From: Terry Kennedy Subject: Re: [rfc] Add boot-time warning messages to PAE kernels To: freebsd-arch@freebsd.org Message-id: <01PDRGFBJ8CO000821@tmk.com> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 07:37:12 -0000 Well, that didn't go over well at all. Makes me wonder if I was being set up by somebody... Personally, I have nothing in this either way. My only experience with the subject area is seeing repeated questions about this on the forums and mailing lists. To address a number of the points raised: > No no no no no. People who are smart enough to build themselves a > different kernel should not get their noses rubbed in your idea of > what's right every time they boot. I run a PAE kernel for my own > reasons, and they are good reasons for me regardless of what you think > about it. They generally show up asking how to build a PAE kernel, because they were led somehow into thinking that PAE was the answer to their problem. Or they managed to build a PAE kernel, but it didn't fix whatever the meta-issue was that led them to PAE in the first place. This wasn't helped by the fact that various documents described the FreeBSD amd64 support as "experimental" until quite recently. For example r248857 finally took it out of the hardware notes. Perhaps if we can find out where users are obtaining incorrect advice to use a PAE kernel instead of amd64, those sources can be corrected as well? > And can we finally lose the mythology that PAE is somehow experimental > or inadequate? I've never encountered a driver that doesn't work with > PAE (I'm sure they exist, but again, people smart enough to build a > custom kernel should be smart enough to deal with testing it with the > devices they use). Well, a "grep nodevice /sys/i386/conf/PAE | wc -l" reports 46 "nodevice" statements disabling hardware which is not supported by the PAE kernel, as well as a complete disabling of module building. > PAE is the way to get NX bit on 32bit kernels. Educate me here - is this non-amd64-capable hardware being used in a production environment, or amd64-capable hardware being run in i386 mode for some reason? I haven't run into any i386 user code that wouldn't run on a FreeBSD amd64 kernel, so I'm trying to see why PAE is the desired solution here. Feel free to go "Because I do, the reasons are none of your business", but I'm genuinely interested. In particular, the several replies saying that for business reasons there can be no warnings would seem to be incompatible with running long out-of- production / out-of-warranty hardware (for the non-amd64-capable case). > The real issue with PAE is that auto-tuning easily makes non-working > configuration due to small KVA (1 or 2 GB) comparing with the available > physical RAM installed on the machine. It is more or less fine for 4GB > machine, but AFAIR, is on the edge for 8GB, and breaks afterward. > Lowering the user/kernel VA split helps somewhat. > > The solution for PAE issues is to implement separate address space for > kernel. It would add some overhead on each mode switch, but this is the > cost of being able to run what you need. This would seem to be an area in need of improvement. But if it doesn't affect the experienced people who are running PAE kernels for good reason, it just becomes another pitfall new users will have to learn about the hard way. > I'd add a && !stfu_warn64 in there somewhere that's set as a tunable. It > is a good seat belt for the newbie running the wrong thing (though maybe > 7 years too late), but experienced users may wish to stifle it for > organizational reasons. Well, it's only 18 months too late if we start when the errant "amd64 is experimental" was excised from the hardware notes. I agree that a tunable in loader.conf makes perfect sense. That's why I prefaced this part of my original post with "[Possibly]". Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 07:46:22 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87A19774 for ; Wed, 15 Oct 2014 07:46:22 +0000 (UTC) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F627CDD for ; Wed, 15 Oct 2014 07:46:21 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id b6so543317lbj.17 for ; Wed, 15 Oct 2014 00:46:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C4y9x99zgkZU5O2VEmvF9zFzTSiHSX50n/eXGgNmI0U=; b=Mn+bLsTi+QRRDhtvhGeLyQvIARHnj0WbI6G4PnrN4wdbfzRxSgjT447coWrlV4WgTU vyJWYKqJhKnmOQD4hNjREWd8Mues92U6JTEF5Tg7ZQ66bwPyhDurL9tf+BDAZ9KQIlaB zckSJ9sRP0HTRLMaYBarYRLcHzJRUWtHObqHQIPDrzhyMWG5J7GcTBCE4WFkt9+Z551H 0B8kN7U4WLL4g+hTUdAlmRvTlk6dZVEYtPqUXBme9NgnTwPsADCefjQmC23bToE/1jen rJM3UOVaN3vPmssLQ9jooJHwrwAtZW4zLuc8SZ/k3E7Xgx9g4o4nitzXrDx6Ed2U/pPf ixYw== X-Gm-Message-State: ALoCoQl1tjMOkzhYtu4wwKf6Vv5q9N9N5+ZmVPYnu7YJXscLF5jg0T5aIhz6+p6sYAmtoRhb333t MIME-Version: 1.0 X-Received: by 10.112.135.229 with SMTP id pv5mr10442368lbb.52.1413359174184; Wed, 15 Oct 2014 00:46:14 -0700 (PDT) Received: by 10.25.23.85 with HTTP; Wed, 15 Oct 2014 00:46:14 -0700 (PDT) X-Originating-IP: [185.58.16.66] In-Reply-To: <20141015061029.GO48641@ivaldir.etoilebsd.net> References: <20141015061029.GO48641@ivaldir.etoilebsd.net> Date: Wed, 15 Oct 2014 08:46:14 +0100 Message-ID: Subject: Re: PIE/PIC support on base From: David Carlier To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 07:46:22 -0000 In first place, we might consider the usual attack targets : /bin/(c)sh /sbin/sendmail /bin/ntp /sbin/dhclient /secure/usr.sbin/sshd .... sendmail, ntp, sshd etc ... are quite sensitive and popular services, hence applying PIE (+ ASLR) will prevent attacks by this bias. /sbin/casperd (hence lib/libcapsicum|libcasper with pic ...) ... as FreeBSD is getting more popularity, such specific FreeBSD's security components might become an appealing target attack. I may have other suggestions in mind (like /sbin/(jail|jexec ... etc) but these are the first step stones. Kind regards. On Wed, Oct 15, 2014 at 7:10 AM, Baptiste Daroussin wrote: > On Mon, Oct 13, 2014 at 11:02:27PM +0100, David Carlier wrote: > > Hi all, > > > > HardenedBSD plans to add PIE support on base in various place. > > > > These are B. Drewery suggestions : > > > > The _pic ones are not needed. The main lib file just needs > > INSTALL_PIC_ARCHIVE=yes. > > > > Modifying CFLAGS in every Makefile is not right, just add a USE_PIE or > > something to pull in common logic from share/mk. > > > > Also I know that, at least for a start, it wished to be applied in some > few > > places, like tcpdump/traceroute, sendmail ... shells ... I thought about > > also casper/capsicum ... ntp ... jail > > > What would probably be interesting is to list binary by binary on which > one you > do want to add the USE_PIE, and with rational explaining why. > > On some OS you often can see ssh(1) not being PIE while sshd(8) have PIE. I > think cherry-picking what should be PIE is the right > > regards, > Bapt > From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 08:31:42 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C4F0416; Wed, 15 Oct 2014 08:31:42 +0000 (UTC) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CF921E8; Wed, 15 Oct 2014 08:31:42 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id i138so603915oig.9 for ; Wed, 15 Oct 2014 01:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f0mgBf4Hz8G9oftU7UKI7mx/rCYbG5upG9k0fZG91YQ=; b=Tsec6mUN+Z38K78o9goWAVpzidS98RoY12og5ZNZmOkyzs8z6fgyTKhspl6KVGO3y2 xEQpK9xMuxsYDKuLIhi4TRVv4rZbpFHKSkLXEHNLo3Kq4vTPfYzPvZEIVh/6R0qLpzsf EObXt8+cQ7kIHQwgGPbCDBU9pXs/fROyD7ks3458XFosGQX951U07QLSQI8cOA1SjAMn UN516n5SLS9nvE68yoPSPZGyhjSPJ9yswzWSeVFuJ70WT59Q3rgq3K2WfMdJ0ztHO4Qh k3sVdKLXTcyahIoEmj90j4vJLbXX4BiXfEHxuMBAMT4TwtJkYc7JZ6KfemyaTJ0TB97D C23Q== MIME-Version: 1.0 X-Received: by 10.60.147.196 with SMTP id tm4mr9477771oeb.4.1413361901790; Wed, 15 Oct 2014 01:31:41 -0700 (PDT) Received: by 10.202.191.213 with HTTP; Wed, 15 Oct 2014 01:31:41 -0700 (PDT) In-Reply-To: References: <20141015061029.GO48641@ivaldir.etoilebsd.net> Date: Wed, 15 Oct 2014 10:31:41 +0200 Message-ID: Subject: Re: PIE/PIC support on base From: Oliver Pinter To: David Carlier Content-Type: text/plain; charset=ISO-8859-1 Cc: Baptiste Daroussin , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 08:31:42 -0000 On 10/15/14, David Carlier wrote: > In first place, we might consider the usual attack targets : > > /bin/(c)sh > /sbin/sendmail > /bin/ntp > /sbin/dhclient > /secure/usr.sbin/sshd .... sendmail, ntp, sshd etc ... are quite sensitive > and popular services, hence applying PIE (+ ASLR) will prevent attacks by > this bias. > /sbin/casperd (hence lib/libcapsicum|libcasper with pic ...) ... as FreeBSD > is getting more popularity, such specific FreeBSD's security components > might become an appealing target attack. > > I may have other suggestions in mind (like /sbin/(jail|jexec ... etc) but > these are the first step stones. > > Kind regards. I think this list should include audit related tools too and all of the setuid programs. > > On Wed, Oct 15, 2014 at 7:10 AM, Baptiste Daroussin > wrote: > >> On Mon, Oct 13, 2014 at 11:02:27PM +0100, David Carlier wrote: >> > Hi all, >> > >> > HardenedBSD plans to add PIE support on base in various place. >> > >> > These are B. Drewery suggestions : >> > >> > The _pic ones are not needed. The main lib file just needs >> > INSTALL_PIC_ARCHIVE=yes. >> > >> > Modifying CFLAGS in every Makefile is not right, just add a USE_PIE or >> > something to pull in common logic from share/mk. >> > >> > Also I know that, at least for a start, it wished to be applied in some >> few >> > places, like tcpdump/traceroute, sendmail ... shells ... I thought >> > about >> > also casper/capsicum ... ntp ... jail >> > >> What would probably be interesting is to list binary by binary on which >> one you >> do want to add the USE_PIE, and with rational explaining why. >> >> On some OS you often can see ssh(1) not being PIE while sshd(8) have PIE. >> I >> think cherry-picking what should be PIE is the right >> >> regards, >> Bapt >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 12:14:15 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C40B2B0 for ; Wed, 15 Oct 2014 12:14:15 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF0A2E8D for ; Wed, 15 Oct 2014 12:14:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9FCEAep085690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2014 15:14:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9FCEAep085690 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9FCEARF085689; Wed, 15 Oct 2014 15:14:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 15 Oct 2014 15:14:10 +0300 From: Konstantin Belousov To: Terry Kennedy Subject: Re: [rfc] Add boot-time warning messages to PAE kernels Message-ID: <20141015121410.GW2153@kib.kiev.ua> References: <01PDRGFBJ8CO000821@tmk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01PDRGFBJ8CO000821@tmk.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 12:14:15 -0000 On Wed, Oct 15, 2014 at 03:35:45AM -0400, Terry Kennedy wrote: > > PAE is the way to get NX bit on 32bit kernels. > > Educate me here - is this non-amd64-capable hardware being used in a > production environment, or amd64-capable hardware being run in i386 mode > for some reason? I haven't run into any i386 user code that wouldn't run > on a FreeBSD amd64 kernel, so I'm trying to see why PAE is the desired > solution here. I do not understand the question. One of the reason for PAE existence at the current times is the ability to get working !PROT_EXEC support on i386 kernel. I have no idea about 'production' environments. WRT user 32bit code which does not run on amd64 kernel, you obviously did not tried hard. The compat32 is lacking; the simple (from the PoV of the kernel facilities used) programs do run, but anything more involved has a chance to meet unimplemented functionality. E.g., should pf control considered management interfaces ? But it is required for things like miniupnpd and squid in transparent mode. From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 14:15:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D632784 for ; Wed, 15 Oct 2014 14:15:17 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F14AD11 for ; Wed, 15 Oct 2014 14:15:16 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XePMB-000POh-Ct; Wed, 15 Oct 2014 14:15:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9FEFEdN049285; Wed, 15 Oct 2014 08:15:14 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19epMOM6XyIM/9UB25L0GqO X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [rfc] Add boot-time warning messages to PAE kernels From: Ian Lepore To: Terry Kennedy In-Reply-To: <01PDRGFBJ8CO000821@tmk.com> References: <01PDRGFBJ8CO000821@tmk.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Oct 2014 08:15:13 -0600 Message-ID: <1413382513.12052.444.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 14:15:17 -0000 On Wed, 2014-10-15 at 03:35 -0400, Terry Kennedy wrote: > Well, that didn't go over well at all. Makes me wonder if I was being > set up by somebody... > > Personally, I have nothing in this either way. My only experience with > the subject area is seeing repeated questions about this on the forums > and mailing lists. To address a number of the points raised: > > > No no no no no. People who are smart enough to build themselves a > > different kernel should not get their noses rubbed in your idea of > > what's right every time they boot. I run a PAE kernel for my own > > reasons, and they are good reasons for me regardless of what you think > > about it. > > They generally show up asking how to build a PAE kernel, because they > were led somehow into thinking that PAE was the answer to their problem. > Or they managed to build a PAE kernel, but it didn't fix whatever the > meta-issue was that led them to PAE in the first place. > > This wasn't helped by the fact that various documents described the > FreeBSD amd64 support as "experimental" until quite recently. For example > r248857 finally took it out of the hardware notes. > > Perhaps if we can find out where users are obtaining incorrect advice > to use a PAE kernel instead of amd64, those sources can be corrected as > well? > Perhaps it's the 'amd' in the name? That always struck me as insane, but it's too late to change now. > > And can we finally lose the mythology that PAE is somehow experimental > > or inadequate? I've never encountered a driver that doesn't work with > > PAE (I'm sure they exist, but again, people smart enough to build a > > custom kernel should be smart enough to deal with testing it with the > > devices they use). > > Well, a "grep nodevice /sys/i386/conf/PAE | wc -l" reports 46 "nodevice" > statements disabling hardware which is not supported by the PAE kernel, as > well as a complete disabling of module building. > The fact that we actively propagate the myth doesn't make it right. The comment even notes that the drivers are "either don't work or untested" I suspect most fall into the latter category. I use a couple devices on the list. I use modules as well, despite the comment that that doesn't work. > > PAE is the way to get NX bit on 32bit kernels. > > Educate me here - is this non-amd64-capable hardware being used in a > production environment, or amd64-capable hardware being run in i386 mode > for some reason? I haven't run into any i386 user code that wouldn't run > on a FreeBSD amd64 kernel, so I'm trying to see why PAE is the desired > solution here. > I didn't say that, and I have no idea what it means. > Feel free to go "Because I do, the reasons are none of your business", > but I'm genuinely interested. > > In particular, the several replies saying that for business reasons there > can be no warnings would seem to be incompatible with running long out-of- > production / out-of-warranty hardware (for the non-amd64-capable case). > I'm not sure where you got the idea that i386 hardware is long out of production. google "industrial single-board computer" some time for an alternate take on what's producing and shipping and still in control of a non-trivial slice of our daily lives. When we ship i386-based products at $work it's using brand new hardware. Sure, some of the hardware we ship with i386 kernels could actually run with amd64 kernels, if we wanted memory usage to go up without any noticible improvement (and perhaps a noticible degradation) in the product's overall performance. There is still important work being done in systems with 256MB or even 64MB of ram. The whole world is not solving the same problems Netflix and Isilon run into every day. > > The real issue with PAE is that auto-tuning easily makes non-working > > configuration due to small KVA (1 or 2 GB) comparing with the available > > physical RAM installed on the machine. It is more or less fine for 4GB > > machine, but AFAIR, is on the edge for 8GB, and breaks afterward. > > Lowering the user/kernel VA split helps somewhat. > > > > The solution for PAE issues is to implement separate address space for > > kernel. It would add some overhead on each mode switch, but this is the > > cost of being able to run what you need. > > This would seem to be an area in need of improvement. But if it doesn't > affect the experienced people who are running PAE kernels for good reason, > it just becomes another pitfall new users will have to learn about the hard > way. > I'm running PAE on this desktop machine so that when I do builds for our i386-based products for work, they're not cross-builds. This machine has 12GB of ram and I've never had a problem with running out of kva. I can imagine there would be configs and workloads where that would be a problem. -- Ian > > I'd add a && !stfu_warn64 in there somewhere that's set as a tunable. It > > is a good seat belt for the newbie running the wrong thing (though maybe > > 7 years too late), but experienced users may wish to stifle it for > > organizational reasons. > > Well, it's only 18 months too late if we start when the errant "amd64 is > experimental" was excised from the hardware notes. > > I agree that a tunable in loader.conf makes perfect sense. That's why I > prefaced this part of my original post with "[Possibly]". > > Terry Kennedy http://www.tmk.com > terry@tmk.com New York, NY USA > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 14:17:39 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DFA189C; Wed, 15 Oct 2014 14:17:39 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 628B6D2E; Wed, 15 Oct 2014 14:17:39 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XePOU-0000k4-DM; Wed, 15 Oct 2014 14:17:38 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9FEHbAC049294; Wed, 15 Oct 2014 08:17:37 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX188yjPU2zuBSEbu1WS7tVVI X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: PIE/PIC support on base From: Ian Lepore To: Baptiste Daroussin In-Reply-To: <20141015061029.GO48641@ivaldir.etoilebsd.net> References: <20141015061029.GO48641@ivaldir.etoilebsd.net> Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Oct 2014 08:17:36 -0600 Message-ID: <1413382656.12052.446.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: David Carlier , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 14:17:39 -0000 On Wed, 2014-10-15 at 08:10 +0200, Baptiste Daroussin wrote: > On Mon, Oct 13, 2014 at 11:02:27PM +0100, David Carlier wrote: > > Hi all, > > > > HardenedBSD plans to add PIE support on base in various place. > > > > These are B. Drewery suggestions : > > > > The _pic ones are not needed. The main lib file just needs > > INSTALL_PIC_ARCHIVE=yes. > > > > Modifying CFLAGS in every Makefile is not right, just add a USE_PIE or > > something to pull in common logic from share/mk. > > > > Also I know that, at least for a start, it wished to be applied in some few > > places, like tcpdump/traceroute, sendmail ... shells ... I thought about > > also casper/capsicum ... ntp ... jail > > > What would probably be interesting is to list binary by binary on which one you > do want to add the USE_PIE, and with rational explaining why. > > On some OS you often can see ssh(1) not being PIE while sshd(8) have PIE. I > think cherry-picking what should be PIE is the right > > regards, > Bapt As long as there's some sort of global knob that says "I want to opt out of this completely regardless of finer-grained controls to the contrary in other makefiles." -- Ian From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 23:27:33 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2028BA3; Wed, 15 Oct 2014 23:27:32 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6DB714A; Wed, 15 Oct 2014 23:27:31 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id n15so1852020lbi.39 for ; Wed, 15 Oct 2014 16:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=d4b2jMm9SpLjoA6gpED3G3vldzmQo0SaRzksE1y7e6Y=; b=axxpx7FuBnHJZM2+4jb3COn7ajrVkSDH8z/js4IoKyelBrH21VEvPylnprLCqrDgld 2DqDKMNyX7fVviaNdJEaPxHDHOvGZNs8JxIYzGfCNIE3GlkMLGyn4v5WRJypuchqfp+E MZ5fBdWKLBe49jNdT5ZKY5tuM4CR70vrlsAqBphEoEzn3Gci1vQL0Ttqd8VSgq5Zxhuc fhZjdITWMgxTBQ0zNzSX9UdlNJ1W7Q1JkjZsEaBNHB6NwX/Z1jsCDhYqtwEXjPMT8kDi /5mWwwh+7fMRDUrMUEGK0TBUzVVOQc0r7oh7MPbSIMK/Yt2fb5o2Fq6y8Dk94/c3Bgc8 +2Zg== MIME-Version: 1.0 X-Received: by 10.112.137.39 with SMTP id qf7mr15488772lbb.47.1413415648835; Wed, 15 Oct 2014 16:27:28 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Wed, 15 Oct 2014 16:27:28 -0700 (PDT) In-Reply-To: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> Date: Wed, 15 Oct 2014 16:27:28 -0700 X-Google-Sender-Auth: h0R44h0CX15g2yxKw8riua0GXPA Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: Kris Moore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , Adrian Chadd , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 23:27:33 -0000 On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: > > It was for a while in 9.2, but we removed it from 10.0 and later due to > stability issues we kept getting reports about. Haven't tried it since > then, dont know if those issues are fixed. > I fixed some of the problems with VIMAGE that I encountered with Bluetooth: https://lists.freebsd.org/pipermail/svn-src-head/2013-July/049582.html Hiroo Onoo submitted this patch, which I committed to fix problems with VIMAGE encountered with removable USB Ethernet: https://lists.freebsd.org/pipermail/svn-src-all/2014-February/081025.html Martin Matuska committed this fix for PF: https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html So a lot of the stability problems with VIMAGE which were in PC-BSD 9.2 and FreeBSD 9.x have been slowly been fixed. -- Craig From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 00:25:06 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3A16B13; Thu, 16 Oct 2014 00:25:06 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49C88919; Thu, 16 Oct 2014 00:25:06 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id fb4so112161wid.6 for ; Wed, 15 Oct 2014 17:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8DBH4UEfflCRvINnK3szZ1MncxMbm9WsXe//DrMd3PE=; b=imLlsVqV/HrubxfRCeB5ABeyAwPLleYWKM0ksSPkWnOGmIzVT02LyWcTSjpWwWghTN 83OhT+Nd0jg0vRSDy4Lmaqu+bAHoXeSIgx89GIT61X5SWOC61lc7TE5xuhsOuJWswnxa QBzbXNl1M685HduaGmAbXNjb/pNkdyiSTiy4WFAIxJPovksNjHuYLYUWKtyJHHuCS2z6 /igoUJPL/cmmxNg2dseeBTBJp++Ahc8zz4Ih9zmc7RDExJBxg4LE2ff55DDMYZjE38D2 YgOlLx1Gpa7AJkHPJZDIAL3z5DIQOim7UmaBjeiIP3mg6ZW7XZsYpXaik40Opk4nQ/CR n04w== MIME-Version: 1.0 X-Received: by 10.180.74.4 with SMTP id p4mr1274205wiv.20.1413419104562; Wed, 15 Oct 2014 17:25:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 15 Oct 2014 17:25:04 -0700 (PDT) In-Reply-To: <1413382513.12052.444.camel@revolution.hippie.lan> References: <01PDRGFBJ8CO000821@tmk.com> <1413382513.12052.444.camel@revolution.hippie.lan> Date: Wed, 15 Oct 2014 17:25:04 -0700 X-Google-Sender-Auth: 1-hxjH6FoQhgHlmwvzKmkqXockA Message-ID: Subject: Re: [rfc] Add boot-time warning messages to PAE kernels From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: Terry Kennedy , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 00:25:06 -0000 [snip] as a note - Intel are pushing their Quark chipset right now which is low powered and (pentium) based. Also note that Atom CPUs may support amd64 but when systems ship with 512MB or 1024MB of RAM, there may not be a pressing need for x86-64. -a From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 00:26:58 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76909C69; Thu, 16 Oct 2014 00:26:58 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97536935; Thu, 16 Oct 2014 00:26:57 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id a1so2583588wgh.9 for ; Wed, 15 Oct 2014 17:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q1uT6/T3MN4pKfArjEXd92O0dhNJey2H2BDNFXVdq4A=; b=X/JeB6B6SJ/3gjg8rsQpbJLXvMY+zElhBtuWz3wtZPdQlBzHkAdc9bq5H2WV3QygvK O2SKkgZbk7pZXA4JWVZExKaJ/nEUrfJ7dSGlGeMpVuo0O035u8dvzkgk31tjSux3gQQO YnO+GAUbsAZTTbtyFpNizqB+ALsjknE73usWs6SftXEw86rAtAUz4FJLJnvK1/eBDeBs 9EOledRqHT02AoaNWQH3LT1TACkcaN0xt9hroEjDyjOxzHO/UkDbJeNni6V1y/CVz1pB mN4F+Uo7gaGW2tT6GQ95KeBLEG7xRLwVKECg7rRfLet+ndOZej54FWVoWAjjFofjknh5 PQlg== MIME-Version: 1.0 X-Received: by 10.194.239.164 with SMTP id vt4mr6395071wjc.131.1413419215912; Wed, 15 Oct 2014 17:26:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 15 Oct 2014 17:26:55 -0700 (PDT) In-Reply-To: References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> Date: Wed, 15 Oct 2014 17:26:55 -0700 X-Google-Sender-Auth: SMVKhLB6kkJhpz-trxxSTgEfVc4 Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Adrian Chadd To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , freebsd-arch , "freebsd-virtualization@freebsd.org" , Kris Moore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 00:26:58 -0000 Something that just popped up here in local hacking is ensuring that all the vnet state is correctly torn down _after_ the system has finished with things that reference it. For example, having the vnet state torn out from underneath say, active TCP timers that haven't yet been cleaned up. Is that fixed or not a problem in -HEAD? -a From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 02:22:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C7C7A9B for ; Thu, 16 Oct 2014 02:22:17 +0000 (UTC) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43123601 for ; Thu, 16 Oct 2014 02:22:17 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.6 #37010) id <01PDSIR06YTS000821@tmk.com> for freebsd-arch@freebsd.org; Wed, 15 Oct 2014 22:22:04 -0400 (EDT) Date: Wed, 15 Oct 2014 21:54:38 -0400 (EDT) From: Terry Kennedy Subject: Re: [rfc] Add boot-time warning messages to PAE kernels To: freebsd-arch@freebsd.org Message-id: <01PDSJPDFY7O000821@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 02:22:17 -0000 > WRT user 32bit code which does not run on amd64 kernel, you obviously > did not tried hard. The compat32 is lacking; the simple (from the PoV > of the kernel facilities used) programs do run, but anything more > involved has a chance to meet unimplemented functionality. Well, everything I've ever tried (including a rather large variety of commercial software) has worked without problems. The only specific case I've ever heard of something not working was Wine, and that only in some anecdotes from others. Improving compatibility, both of FreeBSD-i386 (compat32) and Linux, is a topic for another discussion. Is there a way to search the bug database for this type of enhancement request? I might tackle some of them if I can reproduce the test case(s). > Perhaps it's the 'amd' in the name? That always struck me as insane, > but it's too late to change now. AMD got there first in this case, since Intel was fiddling with their Itanium architecture and seem to have actively resisted extending the x86 architecture to 64 bits. Perhaps this is something that can be ad- dressed in the hardware notes, to make it more obvious that amd64 is not limited to AMD processors. > > Well, a "grep nodevice /sys/i386/conf/PAE | wc -l" reports 46 "nodevice" > > statements disabling hardware which is not supported by the PAE kernel, as > > well as a complete disabling of module building. > > The fact that we actively propagate the myth doesn't make it right. The > comment even notes that the drivers are "either don't work or untested" > I suspect most fall into the latter category. I use a couple devices on > the list. I use modules as well, despite the comment that that doesn't > work. If there are drivers in the nodevice list that are known to work, that would seem to be good info to get into a future revision of the PAE file. Likewise the bit about modules not working. And the PAE manpage has some scary notes (in the BUGS section) as well. > I'm not sure where you got the idea that i386 hardware is long out of > production. google "industrial single-board computer" some time for an > alternate take on what's producing and shipping and still in control of > a non-trivial slice of our daily lives. When we ship i386-based > products at $work it's using brand new hardware. I was speaking of the general x86 desktop / workstation / server market. I had assumed that embedded use of FreeBSD required rather extensive cus- tiomization to fit it in the desired memory space. I had not considered the issue with the NX bit. Like many things with the x86 architecture, it seems to have "just happened", rather than being architected. It might have been better (looking at this in hindsight) if PAE was enabled by default in i386 kernels, but limiting memory accesses to only the memory below the 4GB line unless a tunable enabling the extra memory was set. That seems to have been the method used by Windows to add NX sup- port (minus the tunable). Oh well... In closing, let me withdraw this RFC and withdraw from the field of battle. If someone else wants to float jhb's suggestion for a configur- able warning for an i386 kernel on amd64-capable hardware, either always or for systems with > 4GB, feel free to pick it up. Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 02:55:45 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EFD236B for ; Thu, 16 Oct 2014 02:55:45 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43365902 for ; Thu, 16 Oct 2014 02:55:44 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XebE2-0005Js-3Y; Thu, 16 Oct 2014 02:55:38 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9G2tacV050344; Wed, 15 Oct 2014 20:55:36 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/QrWfo+38SUzkJzRQzaqZX X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [rfc] Add boot-time warning messages to PAE kernels From: Ian Lepore To: Terry Kennedy In-Reply-To: <01PDSJPDFY7O000821@tmk.com> References: <01PDSJPDFY7O000821@tmk.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Oct 2014 20:55:36 -0600 Message-ID: <1413428136.12052.481.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 02:55:45 -0000 On Wed, 2014-10-15 at 21:54 -0400, Terry Kennedy wrote: > > I'm not sure where you got the idea that i386 hardware is long out of > > production. google "industrial single-board computer" some time for an > > alternate take on what's producing and shipping and still in control of > > a non-trivial slice of our daily lives. When we ship i386-based > > products at $work it's using brand new hardware. > > I was speaking of the general x86 desktop / workstation / server market. > I had assumed that embedded use of FreeBSD required rather extensive cus- > tiomization to fit it in the desired memory space. Yeah, if by "extensive customization" you mean a custom kernel config, a makefile that sets a good number of the available WITH and WITHOUT build controls, and an install script that prunes away some of the userland binaries that are big and not needed on a product. The reason I replied in the first place is that everybody speaks of "the general x86 desktop / workstation / server market" as if that covers everything. Embedded folks use FreeBSD too, pretty much out of the box using the existing controls it provides. Sometimes it's a struggle to keep that a viable option, because there are certainly more users in the categories you mentioned. -- Ian From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 08:52:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B516E85; Thu, 16 Oct 2014 08:52:02 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CD367FC9; Thu, 16 Oct 2014 08:52:01 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id D7A2BC506; Thu, 16 Oct 2014 08:52:00 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 772C250BE; Thu, 16 Oct 2014 10:52:02 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Bjoern A. Zeeb" Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> Date: Thu, 16 Oct 2014 10:52:02 +0200 In-Reply-To: <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> (Bjoern A. Zeeb's message of "Mon, 13 Oct 2014 01:07:55 +0000") Message-ID: <86d29so0r1.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Craig Rodrigues , freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 08:52:02 -0000 "Bjoern A. Zeeb" writes: > Also if people are seriously thinking about virtualising pf we need to > import the openbsd/apple pf fix from a few years ago because otherwise > people in virtualised stacks with a /dev/pf can do ugly things. I > think it=E2=80=99s been this one: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2010-3830 There are other serious issues with our current pf (checksum corruption) which I think can only be resolved by importing a newer version. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 14:31:12 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D09CDB76; Thu, 16 Oct 2014 14:31:12 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FD1BD3E; Thu, 16 Oct 2014 14:31:12 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A831E25D3871; Thu, 16 Oct 2014 14:31:09 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 94283C770AE; Thu, 16 Oct 2014 14:31:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id dgJ5OerVOLoh; Thu, 16 Oct 2014 14:31:07 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3DF70C77071; Thu, 16 Oct 2014 14:31:05 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: "Bjoern A. Zeeb" In-Reply-To: <86d29so0r1.fsf@nine.des.no> Date: Thu, 16 Oct 2014 14:31:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> <86d29so0r1.fsf@nine.des.no> To: =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:31:12 -0000 On 16 Oct 2014, at 08:52 , Dag-Erling Sm=F8rgrav wrote: > "Bjoern A. Zeeb" writes: >> Also if people are seriously thinking about virtualising pf we need = to >> import the openbsd/apple pf fix from a few years ago because = otherwise >> people in virtualised stacks with a /dev/pf can do ugly things. I >> think it=92s been this one: >> http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2010-3830 >=20 > There are other serious issues with our current pf (checksum = corruption) > which I think can only be resolved by importing a newer version. Sorry, but you lost context. I was talking about security implications = in VIMAGE context, not about random bugs. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 17:05:03 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F6EB66E; Thu, 16 Oct 2014 17:05:03 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50480103; Thu, 16 Oct 2014 17:05:02 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id s18so3254148lam.37 for ; Thu, 16 Oct 2014 10:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=uBVHkwgVhM/09SM/W1erL0Ng1ruv7pW1JuRa7CN5rxU=; b=jHVGFrV2cZmBhXjBFqhlwshW+ojAQRQguiLW+84g0+bpOeG4X1bFCsCFdJuzprWut4 UyR0dN58N1V1ACKKZMYMVZ7iifihYcOZb/0+PbNTGSu3EyHqPk7O+NVrqS1x2+rphn6t ThoYErJydrymAJbvu52hQHPH5ysOglYl1QMFYidux7/+cR+6EAdJYxl6Cc/QjR4LdQzH Uvih41hmf6bqVwzmZb/yJ8V4wvh0gWJwgy+gzfg5bU4akPTEF4vhsYdkJ1N9Qean7QX9 OlxHoY4aRrKH3bOEbv71xbIs9nh8FDb5KFXqmQzypiYhZcCAHTuzh2/Fs78ZVjRCzGfS iW/w== MIME-Version: 1.0 X-Received: by 10.112.221.226 with SMTP id qh2mr3053717lbc.5.1413479100133; Thu, 16 Oct 2014 10:05:00 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Thu, 16 Oct 2014 10:05:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 10:05:00 -0700 X-Google-Sender-Auth: 6h1wnbx8zJOMVrJ5RGefmCREkss Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:05:03 -0000 On Sat, Oct 11, 2014 at 10:58 AM, Craig Rodrigues wrote: > Hi, > > What action items are left to enable VIMAGE by default for FreeBSD 11? > > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. > > Based on the discussion in this thread, I started writing down a list of action items before enabling VIMAGE by default: https://wiki.freebsd.org/VIMAGE/TODO Does that look reasonable? -- Craig From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 17:39:12 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE748C08; Thu, 16 Oct 2014 17:39:12 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8C560F; Thu, 16 Oct 2014 17:39:12 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5DF36CDCC; Thu, 16 Oct 2014 17:39:10 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 28A94513E; Thu, 16 Oct 2014 19:39:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Bjoern A. Zeeb" Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> <86d29so0r1.fsf@nine.des.no> Date: Thu, 16 Oct 2014 19:39:11 +0200 In-Reply-To: (Bjoern A. Zeeb's message of "Thu, 16 Oct 2014 14:31:02 +0000") Message-ID: <8638anzzgg.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:39:12 -0000 "Bjoern A. Zeeb" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > There are other serious issues with our current pf (checksum > > corruption) which I think can only be resolved by importing a newer > > version. > Sorry, but you lost context. I was talking about security > implications in VIMAGE context, not about random bugs. I realize that, but you're talking about patching our current pf, and I think that's a waste of time; we should import a newer version instead (which I assume already has those patches). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 17:49:03 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C4A4E0C for ; Thu, 16 Oct 2014 17:49:03 +0000 (UTC) Received: from frv198.fwdcdn.com (frv198.fwdcdn.com [212.42.77.198]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD76F75F for ; Thu, 16 Oct 2014 17:49:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=poffVHFriwbO4eGAJ4/WSif1xv21ZW8AU7KbES3HJ64=; b=pvUl91nvZVCB4XTf3D9iCf0TF4hcE9m+bav7dTW5+lI4L+0Yyf3Z3CR4yqdvHBcoxpnFY7SC6cv3ILABlODXo2b1vxXMTFbtq3IEtcqqzm385f3U7hdq98vnFZfT9PMU5TDF+BB4vW9kWWgZYIv76bz6Va9jke34pJxMvu1UchE=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv198.fwdcdn.com with smtp ID 1XepAN-000Exz-WE for freebsd-arch@freebsd.org; Thu, 16 Oct 2014 20:48:47 +0300 Date: Thu, 16 Oct 2014 20:48:47 +0300 From: wishmaster Subject: Re[2]: Enabling VIMAGE by default for FreeBSD 11? To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= X-Mailer: mail.ukr.net 5.0 Message-Id: <1413481493.455723594.213mta8m@frv34.fwdcdn.com> In-Reply-To: <8638anzzgg.fsf@nine.des.no> References: <20141012182551.002b3cc0a45a56d3f34e6174@yamagi.org> <3B4471A7-CDF4-440D-BDD8-3D5B2256B8DD@lists.zabbadoz.net> <7EAA2A23-06F9-44C9-A3E1-62AA37EE5CDA@lists.zabbadoz.net> <86d29so0r1.fsf@nine.des.no> <8638anzzgg.fsf@nine.des.no> MIME-Version: 1.0 Received: from artemrts@ukr.net by frv34.fwdcdn.com; Thu, 16 Oct 2014 20:48:47 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: "Bjoern A. Zeeb" , freebsd-arch , freebsd-virtualization@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:49:03 -0000 --- Original message --- From: "Dag-Erling Smørgrav" Date: 16 October 2014, 20:39:22 > "Bjoern A. Zeeb" writes: > > Dag-Erling Smørgrav writes: > > > There are other serious issues with our current pf (checksum > > > corruption) which I think can only be resolved by importing a newer > > > version. > > Sorry, but you lost context. I was talking about security > > implications in VIMAGE context, not about random bugs. > > I realize that, but you're talking about patching our current pf, and I > think that's a waste of time; we should import a newer version instead > (which I assume already has those patches). > Forget about importing new version of PF from OS, which doesn't has virtualized inet stack. Cheers, w From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 18:21:45 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9F6EB17 for ; Thu, 16 Oct 2014 18:21:45 +0000 (UTC) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D237B26 for ; Thu, 16 Oct 2014 18:21:45 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id pn19so3419523lab.0 for ; Thu, 16 Oct 2014 11:21:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=aJPvKkX+sMcR6zwMdzfEdx1V19IrCRrzkyryOVbHgyc=; b=BwrWmeNIBY/GRn0Nl1vFkB8btTVI9KdOaf5RWuwN11PugFszY5PAaav4gQgpqj/4Ng b5QJCiD12MZKIhdZyQzXBq5Qu+lm6ZbL3ppuZVDQCMmfr1/JiH3iaUJixPsgOTy+pZBh zBncB1hmPmNOOZj1quzbWh4MUgygwFPMiUfJEf0VqJnIxB/VrGGMXpHdi+k1/ynj1g+K t+i3E29+HnyhDPeIHrmPjhcHFh2YxuZ1bUSMMP+GFBjRpCip6HyY/1RjUEyKmIuGOK5Z bWRviGY6G6zF2WuWNLWOWJ+O2iY3apZ20eyH/HbDPYhrC3DDy/SWE6wVhcRJlq3A+YeH AK6A== X-Gm-Message-State: ALoCoQmb/e2CrvDX0Jm/pzMr7B3c60dYZQfHzWwBTECpbXBVEj/OWz+SOCPRXlwH/CeDlTN5LgoB MIME-Version: 1.0 X-Received: by 10.112.97.135 with SMTP id ea7mr3583350lbb.46.1413483702905; Thu, 16 Oct 2014 11:21:42 -0700 (PDT) Received: by 10.25.23.85 with HTTP; Thu, 16 Oct 2014 11:21:42 -0700 (PDT) X-Originating-IP: [80.111.192.87] In-Reply-To: References: Date: Thu, 16 Oct 2014 19:21:42 +0100 Message-ID: Subject: Re: PIE/PIC support on base From: David Carlier To: Jeremie Le Hen , freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:21:46 -0000 I chose the "atomic" approach, at the moment very few binaries are concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the needed libraries plus created WITH_PIE which add fPIE/fpie -pie flags only if you include (which include ...) otherwise other binaries include as usual hence does not apply. Look reasonable approach ? On Thu, Oct 16, 2014 at 10:35 AM, Jeremie Le Hen wrote: > Hi David, > > On Tue, Oct 14, 2014 at 12:02 AM, David Carlier > wrote: > > Hi all, > > > > HardenedBSD plans to add PIE support on base in various place. > > > > These are B. Drewery suggestions : > > > > The _pic ones are not needed. The main lib file just needs > > INSTALL_PIC_ARCHIVE=yes. > > > > Modifying CFLAGS in every Makefile is not right, just add a USE_PIE or > > something to pull in common logic from share/mk. > > > > Also I know that, at least for a start, it wished to be applied in some > few > > places, like tcpdump/traceroute, sendmail ... shells ... I thought about > > also casper/capsicum ... ntp ... jail > > Is it worth the time spent? I mean, what is the drawback of enabling > PIE "world"-wide and provide a setting which can be used globally or > per-lib/binary to override this? This is what I did back when SSP was > introduced. > > Just to save one round trip in case someone answers that PIE binaries > are slower: I think this claim needs a benchmark :). > > -- > Jeremie Le Hen > jlh@FreeBSD.org > From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 19:23:24 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 205DAF8F for ; Thu, 16 Oct 2014 19:23:24 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1D371B7 for ; Thu, 16 Oct 2014 19:23:23 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id l18so4487370wgh.5 for ; Thu, 16 Oct 2014 12:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=VltS9oHySf+H3gnmTFYej+rhhPeqEJ2x9VxmM4sHU4g=; b=qyMNG1L0St1Wilo82rN8fpu7gnfb0Nn5YuilgbEH/HFlgU+D5Cmt3A96Zwff3ZYN2E KWVwQmBuk/yX2geaudmqJss8/4mrkSFqPmywIemV9E4/402KeJ7yQxqwXQ4yyS9SEpbz 1cKczcz3s0DTJQ7zfoMiTdmF06wCrfZMdvLvZYxN53Hen60fT32hybkMdC0S+mXllHQr SvULIH5EhLTgP7C8yQOpkBCqkPRehcSlXgqGQTTMWrIDxlnX6tmowKCi/6em4Hrqaze3 FQkCMFKbFbIma+hlGPUtlbpa99MsZE7Gk+JQKis31YuTrvqL7D/RSGJ/cirEEln1Bp0W fH8g== MIME-Version: 1.0 X-Received: by 10.180.74.4 with SMTP id p4mr8396729wiv.20.1413487402039; Thu, 16 Oct 2014 12:23:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 16 Oct 2014 12:23:21 -0700 (PDT) Date: Thu, 16 Oct 2014 12:23:21 -0700 X-Google-Sender-Auth: EH4zWQtEr7IEvCER_yrHKBDjYbY Message-ID: Subject: [rfc] extend cpuid from u_char -> int in struct thread; kproc_info and ule From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:23:24 -0000 Hi, https://reviews.freebsd.org/D955 This extends some cpuid fields from u_char -> int. This does change the ABI a little - it leaves the older u_char fields in place but they'll wrap at CPU IDs > 255. Thanks, -a From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 21:59:53 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0B22274 for ; Thu, 16 Oct 2014 21:59:53 +0000 (UTC) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F57B790 for ; Thu, 16 Oct 2014 21:59:53 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id hq11so3392011vcb.22 for ; Thu, 16 Oct 2014 14:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=l1F9RHYdJxV1YTH3t1WkLqQSEVqGknm58MykKfGjFHs=; b=gJLALuiYyNgsozf/HxasRV+OGC8yDtKQTdDBp7bwrs58Sjpat4C/L47RDPB3gJHQXT iXV+8hB+4Kr8GKMdi7yyQxHGydVt9nRlLkfIRmEM7+pmaWewdbpEkrkJSg7ZL4F9H2/i mQn9cSjdjgwMZAdxRODEHIpmOwvYuvHH+KFnWTpy1K0sO+Q2Dj1gONN3yDj8SCiilWFK LTFqmwMbbySM8fqRw5p2P3llvI7lqU33yPZCXBnhYsqm8yQ1RpyslSZIs0RR9cgWiR1S 7AgoNYLspNizI5MvjC4PyF+V5Jaf4hqQXJHO4Ir6dDRnJkEGR5+N08d8I3G+unaBYgy0 ZWTg== MIME-Version: 1.0 X-Received: by 10.52.99.199 with SMTP id es7mr3127927vdb.61.1413496792611; Thu, 16 Oct 2014 14:59:52 -0700 (PDT) Sender: jlehen@gmail.com Received: by 10.31.136.79 with HTTP; Thu, 16 Oct 2014 14:59:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 23:59:52 +0200 X-Google-Sender-Auth: Wr4SvKvKjFppryH9Utap8QVBE3Q Message-ID: Subject: Re: PIE/PIC support on base From: Jeremie Le Hen To: David Carlier Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:59:53 -0000 On Thu, Oct 16, 2014 at 8:21 PM, David Carlier wrote: > > I chose the "atomic" approach, at the moment very few binaries are > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the needed > libraries plus created WITH_PIE which add fPIE/fpie -pie flags only if you > include (which include ...) otherwise other > binaries include as usual hence does not apply. Look > reasonable approach ? I think I understand what you mean. But I think PIE is commonplace nowadays and I don't understand what you win by not enabling it for the whole system. Is it a performance concern? Is it to preserve conservative minds from to much change? :) -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 22:12:54 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B0F9EEB; Thu, 16 Oct 2014 22:12:54 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3787919; Thu, 16 Oct 2014 22:12:53 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id n15so3642652lbi.11 for ; Thu, 16 Oct 2014 15:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=JP2Xx+XBRiaIVEIsPugrOYyzWwZ/GYrWHOfk/JUuOLk=; b=lVTyqwTNaDlNV5QzI+ulaWBOgQoJlj6SINMqTb4AcV7eQ4yvUbV8dulc4xNFEaln3D 5E8Wa5Fr9O1I7X7iywncOuypo3EhWD+y1UvUbN+hfKqigYLUusysXNS6xr48OEWiDUpe 33iaaZvSsFyIVA0+vFgy/yia7nuCZOusDYyVabPMQDJgx1KdQRpoRPHMj+z6b47KmBP2 EdkDelWu0i+Ry91E8h+AUd1eMduhIArTVOg5HUh2SZODBrA/npM9DyJs6FXHMfnblxyT g1xpf/f1pwvBBvUkUjMZo2uEyDs1bXbtv4iigl0gfCUefIzmv4VQ3QvuG+z3Gj19NPV/ VzoQ== X-Received: by 10.112.169.66 with SMTP id ac2mr4525326lbc.73.1413497571756; Thu, 16 Oct 2014 15:12:51 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id oh4sm8172495lbc.19.2014.10.16.15.12.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Oct 2014 15:12:50 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 17 Oct 2014 00:12:47 +0200 From: Baptiste Daroussin To: Jeremie Le Hen Subject: Re: PIE/PIC support on base Message-ID: <20141016221247.GB37244@ivaldir.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: David Carlier , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:12:54 -0000 --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 16, 2014 at 11:59:52PM +0200, Jeremie Le Hen wrote: > On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > wrote: > > > > I chose the "atomic" approach, at the moment very few binaries are > > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the needed > > libraries plus created WITH_PIE which add fPIE/fpie -pie flags only if = you > > include (which include ...) otherwise ot= her > > binaries include as usual hence does not apply. Look > > reasonable approach ? I would more like the USE_PIE=3Dyes approach (Warner would have a better vi= ew on the proper approach :)) and make bsd.prog.mk aware of it. >=20 > I think I understand what you mean. But I think PIE is commonplace > nowadays and I don't understand what you win by not enabling it for > the whole system. Is it a performance concern? Is it to preserve > conservative minds from to much change? :) >=20 I have not seen any operating system where PIE is enabled by default on eve= ry single binaries, and yes PIE has a performance inpact. It also have an infrastructue cost meaning we have to create PIC enabled ar= chive for at least every single INTERNALLIB and cherrypick the right .a depending= on the target we are building (static binaries or dynamic one). regards, Bapt --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRAQt8ACgkQ8kTtMUmk6EzeeACfYnKGA/aG1YhGwGhESPfGfjy8 +WMAoLEY9hVPXUdj1XRH+I0oaszuvwXS =vop5 -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 22:15:41 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B6233AD; Thu, 16 Oct 2014 22:15:41 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 976E1943; Thu, 16 Oct 2014 22:15:40 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id l18so4739782wgh.17 for ; Thu, 16 Oct 2014 15:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f1/IRrSObsrfjODYvRe0ARDnTZRKbhy6lzYgvMvLvNY=; b=KbQ148IJc9XGCC3iPTZgQo1mwP8SFFFVWhvBKVkpAfYUbXaD6jIvg/3sCzzfYVhDgQ 1Q/fLsRDQ9bMgo7PX7DWc/8g64Oqzs/FCYvO184bI4P52Uecd2LzrvPTdOU4zqA4a9fC s4bRbjhEkkL+1yFKbPDn/9lrzJMTE5phqcU1FMNZGfbHDZie7rNybYfHiRE55IVMIrHj UyzUGyY5FfXwJD9jw1pFeOA3jNtzKDBLRmXDe1iJxEOawMOZGPtwETYaCnYXt6Yc3DqY d0Yp/eiTUEPmMfkeQu9OR3vNPAvbwt1mSypmuQCbOUG1QjLr0mVLNF2n2OnsAvaCWA/8 9gqA== MIME-Version: 1.0 X-Received: by 10.180.37.143 with SMTP id y15mr24039987wij.29.1413497738830; Thu, 16 Oct 2014 15:15:38 -0700 (PDT) Received: by 10.216.141.6 with HTTP; Thu, 16 Oct 2014 15:15:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 18:15:38 -0400 Message-ID: Subject: Re: PIE/PIC support on base From: Shawn Webb To: Jeremie Le Hen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hunger@hunger.hu, David Carlier , Oliver Pinter , Sean Bruno , Konstantin Belousov , freebsd-arch@freebsd.org, PaX Team , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:15:41 -0000 On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen wrote: > On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > wrote: > > > > I chose the "atomic" approach, at the moment very few binaries are > > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the needed > > libraries plus created WITH_PIE which add fPIE/fpie -pie flags only if > you > > include (which include ...) otherwise > other > > binaries include as usual hence does not apply. Look > > reasonable approach ? > > I think I understand what you mean. But I think PIE is commonplace > nowadays and I don't understand what you win by not enabling it for > the whole system. Is it a performance concern? Is it to preserve > conservative minds from to much change? :) Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Bruno. On i386, there is a performance cost due to not having an extra register available for the relocation work that has to happen. PIE doesn't carry much of a performance penalty on amd64, though it still does carry some on first resolution of functions (due to the extra relocation step the RTLD has to worry about). On amd64, after symbol resolution has taken place, there is no further performance penalty due to amd64 having an extra register to use for PIE/PIC. I'm unsure what, if any, performance penalty PIE carries on ARM, AArch64, and sparc64. Certain folk would prefer to see PIE enabled only in certain applications. /bin/ls can't really make much use of PIE. But sshd can. I personally would like to see all of base's applications compiled as PIEs, but that's a long ways off. It took OpenBSD several years to accomplish that. Having certain high-visibility applications (like sshd, inetd, etc) is a great start. Providing a framework for application developers to opt their application into PIE is another great start. Those are my two cents. Thanks, Shawn From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 22:37:31 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D585A05 for ; Thu, 16 Oct 2014 22:37:31 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67799B12 for ; Thu, 16 Oct 2014 22:37:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s9GMbUkL058311 for ; Thu, 16 Oct 2014 22:37:30 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s9GMbUuO058306 for freebsd-arch@freebsd.org; Thu, 16 Oct 2014 22:37:30 GMT (envelope-from bdrewery) Received: (qmail 93505 invoked from network); 16 Oct 2014 17:37:28 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 16 Oct 2014 17:37:28 -0500 Message-ID: <5440489F.3080602@FreeBSD.org> Date: Thu, 16 Oct 2014 17:37:19 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Shawn Webb , Jeremie Le Hen Subject: Re: PIE/PIC support on base References: In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6Tb6gTjdRxSCIkUiVFqTJCoctTLJg4Jju" Cc: hunger@hunger.hu, David Carlier , Oliver Pinter , Sean Bruno , Konstantin Belousov , freebsd-arch@freebsd.org, PaX Team X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:37:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6Tb6gTjdRxSCIkUiVFqTJCoctTLJg4Jju Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/16/2014 5:15 PM, Shawn Webb wrote: >=20 >=20 > On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen > wrote: >=20 > On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > > wrote: > > > > I chose the "atomic" approach, at the moment very few binaries ar= e > > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the = needed > > libraries plus created WITH_PIE which add fPIE/fpie -pie flags on= ly if you > > include > (which include= > >...) otherwise other > > binaries include > as usual henc= e does not apply. Look > > reasonable approach ? >=20 > I think I understand what you mean. But I think PIE is commonplace= > nowadays and I don't understand what you win by not enabling it for= > the whole system. Is it a performance concern? Is it to preserve > conservative minds from to much change? :) >=20 >=20 > Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Bruno.= >=20 > On i386, there is a performance cost due to not having an extra registe= r > available for the relocation work that has to happen. PIE doesn't carry= > much of a performance penalty on amd64, though it still does carry some= > on first resolution of functions (due to the extra relocation step the > RTLD has to worry about). On amd64, after symbol resolution has taken > place, there is no further performance penalty due to amd64 having an > extra register to use for PIE/PIC. I'm unsure what, if any, performance= > penalty PIE carries on ARM, AArch64, and sparc64. >=20 I think if the performance impact can be well understood on all architectures, and that it is not more than a few % points, other people may be more willing to enable it on all. I can't speak for them, but if the impact is not significant then it is safer and simpler to enable everywhere and I would think that argument would win over anything else. What do I know though? That approach failed already. > Certain folk would prefer to see PIE enabled only in certain > applications. /bin/ls can't really make much use of PIE. But sshd can. = I > personally would like to see all of base's applications compiled as > PIEs, but that's a long ways off. It took OpenBSD several years to > accomplish that. Having certain high-visibility applications (like sshd= , > inetd, etc) is a great start. Providing a framework for application > developers to opt their application into PIE is another great start. >=20 > Those are my two cents. >=20 > Thanks, >=20 > Shawn=20 --=20 Regards, Bryan Drewery --6Tb6gTjdRxSCIkUiVFqTJCoctTLJg4Jju 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.10 (MingW32) iQEcBAEBAgAGBQJUQEifAAoJEDXXcbtuRpfPGpcH/i2FCR+S5iFns4VqxcxupJRB Fx5Me/j1l8WPOIjnsCDAa6Ojz178YuaTl7SCAPSrCG7+NE0X1XpSmeqMXzx4TSZu IbxgMVQnHrgR0Wde02l0chStIRBPZs8RrOis8QvfrRtWKelSLe1swkSNguAR4onE xD6XpbOsM5/Kl1lwde9WAkL0/20vjuChl5k0FHEJNWifImiwz+5t5/NRpxYKX8en dph8Ownh0Iskp1Wl/2qVh7yOtl5rcOqKrSGb0+WPxfjowXMVx6C91xKQtmqLxaAg GFVArVU3hsWjxzrxhgLD2K/M4OJXy6Iy8/Jkr0pY/dDlqy/2T3iTWBCF5yiVMPA= =/Lxy -----END PGP SIGNATURE----- --6Tb6gTjdRxSCIkUiVFqTJCoctTLJg4Jju-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 23:33:42 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0888A7D1; Thu, 16 Oct 2014 23:33:42 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F384CE0; Thu, 16 Oct 2014 23:33:40 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id p9so3614448lbv.21 for ; Thu, 16 Oct 2014 16:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ftsk/FZ3M8utYXN6LOmwgsdC6mf1618VGi2lsTOshuc=; b=TMtXCXrMMCuE4uRCRZ2m/Xlyu42MIzP+u9ms4Orso+U1UVq4GvN/r7hilnWVbVucAu YzhQuBJfoKxFaCariADo3qm+t2+7/rzllJQWjZcs7UcDmw9Riag3SYqezAoE1ZizjMRi +hkkMOuzN/0F+l7/60nkfuJ4M8OyP029GjJgrLrvOTZWaNzqTQURZIf0WLXjo3Q6rgzE RI2s561sbqJsckLQfQgOwKiHLuYECAZrciANtRTMsFWB3wBox+uuqmnlbd2aMGle/LxU Nrrkmt7AEzEcsWoleUkTQqC6rddPvhtaLSnVpL4+1Dr9aohTbCpYp8Gn9DZOnaVT350a N/7w== MIME-Version: 1.0 X-Received: by 10.112.148.161 with SMTP id tt1mr4861879lbb.67.1413502418889; Thu, 16 Oct 2014 16:33:38 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Thu, 16 Oct 2014 16:33:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 16:33:38 -0700 X-Google-Sender-Auth: XqKkRDMJt4Q0fnyIXupkWRvX1-Y Message-ID: Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 23:33:42 -0000 On Sat, Oct 11, 2014 at 11:15 PM, Adrian Chadd wrote: > ... is it enabled by default on pcbsd? > Kris has answered the question about pcbsd and VIMAGE. As an additional datapoint, I would like to point out that VIMAGE has been enabled in FreeNAS for some time: https://github.com/freenas/freenas/blob/master/build/nanobsd-cfg/FREENAS.amd64 -- Craig From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 04:56:03 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0E818AC for ; Fri, 17 Oct 2014 04:56:03 +0000 (UTC) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 668E1E8 for ; Fri, 17 Oct 2014 04:56:02 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id p9so53655lbv.19 for ; Thu, 16 Oct 2014 21:55:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=p9yG/l3CkyXOUoeMI3Xeix7yRXBdCyR/fIVF8pMl4H8=; b=B18eAEiMRT/UlQYakG1guG2rI7N230UIMA03k8lKpJFIBRFnZ9tuk/q2ffssKQXN2o WBYkkUx6ISnOiu4YIMxkNYh5I1qbaG1/NKkKnWXA0690hBpr6i82k0IIf82uw1Xmo96f B6XPuRqEuZ0Tg3vSJiSjATCHPpAkEo3IDCjYRz4DId9ojtp1v7s8xuorHbfYGd6d8OwL 93VSWIbpaObQGbmxdhrM+AufhKAEi0L/VlgMfQS6xAcJemIG2Wz0M1RVxaqrK+ufatEy ekuG/CFOKSp3rWoJYY8IOZSDo7Ki/Z9Ft9WFLjJSRVe6CT/b51kC7JIDaEPR+9RLABGi g8sg== X-Gm-Message-State: ALoCoQmm38L3OxQ03d7qBRxCIqNDFjcmTLyh8na8QTXPalRG/okdoT+coFwHgT/Jg+4R5e7BjEsS MIME-Version: 1.0 X-Received: by 10.152.19.133 with SMTP id f5mr410463lae.87.1413521755521; Thu, 16 Oct 2014 21:55:55 -0700 (PDT) Received: by 10.25.23.85 with HTTP; Thu, 16 Oct 2014 21:55:55 -0700 (PDT) X-Originating-IP: [80.111.192.87] In-Reply-To: References: <5440489F.3080602@FreeBSD.org> Date: Fri, 17 Oct 2014 05:55:55 +0100 Message-ID: Subject: Fwd: PIE/PIC support on base From: David Carlier To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 04:56:04 -0000 ---------- Forwarded message ---------- From: David Carlier Date: Fri, Oct 17, 2014 at 5:52 AM Subject: Re: PIE/PIC support on base To: Jeremie Le Hen , Baptiste Daroussin , Shawn Webb Except Baptiste, what do you all think about USE_PIE versus WITH_PIE ? On Thu, Oct 16, 2014 at 11:37 PM, Bryan Drewery wrote: > On 10/16/2014 5:15 PM, Shawn Webb wrote: > > > > > > On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen > > wrote: > > > > On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > > > > wrote: > > > > > > I chose the "atomic" approach, at the moment very few binaries are > > > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the > needed > > > libraries plus created WITH_PIE which add fPIE/fpie -pie flags > only if you > > > include > (which include > > >...) otherwise other > > > binaries include > as usual > hence does not apply. Look > > > reasonable approach ? > > > > I think I understand what you mean. But I think PIE is commonplace > > nowadays and I don't understand what you win by not enabling it for > > the whole system. Is it a performance concern? Is it to preserve > > conservative minds from to much change? :) > > > > > > Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Bruno. > > > > On i386, there is a performance cost due to not having an extra register > > available for the relocation work that has to happen. PIE doesn't carry > > much of a performance penalty on amd64, though it still does carry some > > on first resolution of functions (due to the extra relocation step the > > RTLD has to worry about). On amd64, after symbol resolution has taken > > place, there is no further performance penalty due to amd64 having an > > extra register to use for PIE/PIC. I'm unsure what, if any, performance > > penalty PIE carries on ARM, AArch64, and sparc64. > > > > I think if the performance impact can be well understood on all > architectures, and that it is not more than a few % points, other people > may be more willing to enable it on all. I can't speak for them, but if > the impact is not significant then it is safer and simpler to enable > everywhere and I would think that argument would win over anything else. > What do I know though? That approach failed already. > > > Certain folk would prefer to see PIE enabled only in certain > > applications. /bin/ls can't really make much use of PIE. But sshd can. I > > personally would like to see all of base's applications compiled as > > PIEs, but that's a long ways off. It took OpenBSD several years to > > accomplish that. Having certain high-visibility applications (like sshd, > > inetd, etc) is a great start. Providing a framework for application > > developers to opt their application into PIE is another great start. > > > > Those are my two cents. > > > > Thanks, > > > > Shawn > > > -- > Regards, > Bryan Drewery > > From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 05:23:15 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24DEEB6F for ; Fri, 17 Oct 2014 05:23:15 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D987C341 for ; Fri, 17 Oct 2014 05:23:14 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id h15so963178igd.10 for ; Thu, 16 Oct 2014 22:23:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=kYFgMIPgZSCGNr7kEMromGTYbd7+VpIQwxUHA+rZnzk=; b=P1VKsKhm+fsgduqjufdu+96rlF4tYZD93YOQKGk53wCynrr7MnRzey/3Top2iNFZe2 wV8f5ajVJ5Gx02uc8irKUZwPHMKCaSnes5aRBSTgcS/uHgRPy5IAVc/NrM/P/df6k9Kf qr/sqQjkYEaYYLdhPVNq3X5JefGY7U9zacUq6KJFVLwb3UCtFiAaviXFjlGl/oA9KXgS 3FWVx2zMchvcOaEYP3E8d6Jga8nohpSD+iQSSjCNqPi6JNZv0sfB1FjT79Ke7BxrVBFS QO5pX9TKrXnkVTmoJakDrx52HFJHo8EnVSDlq18t3+xQ7itaSIGR5kFwTUvSoUEEULN3 FBdw== X-Gm-Message-State: ALoCoQkSy3rNKxA37G1Yq6HO/0bqTqY60xghZoW/DhdQQRvdHSfrG/tAjtOgy1Dh6SDWIZsHdmva X-Received: by 10.42.151.66 with SMTP id d2mr3744icw.74.1413523387893; Thu, 16 Oct 2014 22:23:07 -0700 (PDT) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id o8sm458329igh.12.2014.10.16.22.23.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 22:23:07 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_8935A690-5D2F-4271-AB81-E4E9D5D145BA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: PIE/PIC support on base From: Warner Losh In-Reply-To: Date: Thu, 16 Oct 2014 22:23:04 -0700 Message-Id: <35058403-E24F-4243-ABD1-CE82A1764977@bsdimp.com> References: <5440489F.3080602@FreeBSD.org> To: David Carlier X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 05:23:15 -0000 --Apple-Mail=_8935A690-5D2F-4271-AB81-E4E9D5D145BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 So, WITH_PIE -> MK_PIE =3D=3D yes. This says =93for the things that support PIE, build them.=94 This would = be a user-accessable knob (not Makefile accessible) that would enable things. MK_PIE would = likely be tested in some *.mk files, and maybe in some Makefiles but likely not. = Makefiles are absolutely forbidden[*] from setting WITHOUT_foo or WITH_foo. And then there=92s =93USE_PIE" What does that mean? There=92s nothing else in the src tree that uses = that paradigm, except in the obscure backwater of bsd.doc.mk, which is used for just = share/doc documents. There it used control which tools in the pic / tbl / etc are = used. If it is defined, then the tool is placed in the chain. It is a Makefile only = setting that=92s not a user accessible part. This suggests that we could rescue it from this = obscure corner. It=92s also used in ports to enable a features, but in a different way = than we=92re describing here. It describes a dependency chain needed for the port, rather than = turning on or off a latent feature. What do you propose it to mean? What do you propose USE_foo to mean = generally? Are there other options in the tree that would make sense to transition = to USE_xxx. Does it just have to be defined, or is there a value associated with it? = USE_xxx=3D{yes,no} would mean what exactly in a Makefile? The whole reason we went to = MK_xxx in the past was because it was too difficult to change the defaults for = some option. Used carefully, USE_xxx might not fall into that trap, but I=92m skeptical. Today, things like this are done with NO_xxxx in a few places. We have a = small number of these in the tree. NO_PIC, NO_INFO_COMPRESS, NO_EXTRADEPEND, NO_FSCHG, NO_LINT, NO_SUBDIR, NO_MLINKS, NO_OBJ, and the infamous NO_SHARED. They mean a variety of different things. Some are ancient = vestiges of the system of user configuration that predates MK_foo. Some are set = in Makefiles to control things. Some are a bit of both. And there are no words to = described NO_SHARED=3Dno, which is what lead, in part, to the NOxxx jihad of the = late 1990s. I=92d rather like to avoid any new NO options. Oh, and I=92m glad YES_HESIOD = is now in the dustbin of history. If I were designing things, I=92d suggest we invent something new. = ENABLE_xxx and DISABLE_xxx which would change the default behavior around the xxx = feature. Warner [*] Except the top level Makefile and some in release/=85 But these uses = are transitioning to MK_xxx=3D{yes,no} instead. On Oct 16, 2014, at 9:55 PM, David Carlier = wrote: > ---------- Forwarded message ---------- > From: David Carlier > Date: Fri, Oct 17, 2014 at 5:52 AM > Subject: Re: PIE/PIC support on base > To: Jeremie Le Hen , Baptiste Daroussin = , > Shawn Webb >=20 >=20 > Except Baptiste, what do you all think about USE_PIE versus WITH_PIE ? >=20 > On Thu, Oct 16, 2014 at 11:37 PM, Bryan Drewery > wrote: >=20 >> On 10/16/2014 5:15 PM, Shawn Webb wrote: >>>=20 >>>=20 >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen >> > wrote: >>>=20 >>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier >>> >> > wrote: >>>>=20 >>>> I chose the "atomic" approach, at the moment very few binaries are >>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the >> needed >>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flags >> only if you >>>> include > (which include >>> >...) otherwise other >>>> binaries include > as usual >> hence does not apply. Look >>>> reasonable approach ? >>>=20 >>> I think I understand what you mean. But I think PIE is = commonplace >>> nowadays and I don't understand what you win by not enabling it = for >>> the whole system. Is it a performance concern? Is it to = preserve >>> conservative minds from to much change? :) >>>=20 >>>=20 >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean = Bruno. >>>=20 >>> On i386, there is a performance cost due to not having an extra = register >>> available for the relocation work that has to happen. PIE doesn't = carry >>> much of a performance penalty on amd64, though it still does carry = some >>> on first resolution of functions (due to the extra relocation step = the >>> RTLD has to worry about). On amd64, after symbol resolution has = taken >>> place, there is no further performance penalty due to amd64 having = an >>> extra register to use for PIE/PIC. I'm unsure what, if any, = performance >>> penalty PIE carries on ARM, AArch64, and sparc64. >>>=20 >>=20 >> I think if the performance impact can be well understood on all >> architectures, and that it is not more than a few % points, other = people >> may be more willing to enable it on all. I can't speak for them, but = if >> the impact is not significant then it is safer and simpler to enable >> everywhere and I would think that argument would win over anything = else. >> What do I know though? That approach failed already. >>=20 >>> Certain folk would prefer to see PIE enabled only in certain >>> applications. /bin/ls can't really make much use of PIE. But sshd = can. I >>> personally would like to see all of base's applications compiled as >>> PIEs, but that's a long ways off. It took OpenBSD several years to >>> accomplish that. Having certain high-visibility applications (like = sshd, >>> inetd, etc) is a great start. Providing a framework for application >>> developers to opt their application into PIE is another great start. >>>=20 >>> Those are my two cents. >>>=20 >>> Thanks, >>>=20 >>> Shawn >>=20 >>=20 >> -- >> Regards, >> Bryan Drewery >>=20 >>=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" --Apple-Mail=_8935A690-5D2F-4271-AB81-E4E9D5D145BA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQKe5AAoJEGwc0Sh9sBEAM2sQALzy1KX+GNAJhiAElptO9i+h 65ymN3MbBUd4dksVqPYU6w6kVe+nFzcqMCg+zWlHdjdy+Gf+Vo9rSELPOkw5T38S W+UHtd4NSgNxyLW3anMpyWo6tJkkGlz5ReOn9JKPoSwfj0tSQwU8fGhpFDd2e1YJ uMNN+6aMvbVQYaw/wXTCS4SazG0GTI7Ts9LP3mKolODHW8ZU30pElA7UP7sGN/qD q5AfvcVrXR7aJGL/RUGJHaDIQ4KiYRRcDNsOlOVYoKNO1Q4flJuNrk5i68u2DVll ZhANqkZQOWgsiPGoktuVIUDOGPzcK39raDGlQDSSShNQ9xLcJjoP1DyxyvlfsfwA ozeCNajvxvrGtxlAIXLuQ7z0xCnmh7I2WFTgu3bCajYSLapeS1sxxTzrTmqJY+Sr T0OXtePBJvjAFOEveEmiZ7s8O5+XMP1lnobqLuuVxcEcEYyCUVc4CCcg6x/8bBBN REVyrBqNUoXCavPBkBwUXfzPkrwHxH0We7jNQqzFLw9np2UgwQrboBEcgwUoxnDf vI1Dm8tO9zcdPxdXr/mVUMTJgqiPM0RyinEcDU2pfghkeRXVA4+7e7ucJOQwgvpD 6dfz672K4tB2bNHTWNrrsBqxVagUBS5Z9FdBj90j983FJYNVE6uNuc2lsjeWc5VL 7OFe1sEURtUuHrqhOj7l =vuUW -----END PGP SIGNATURE----- --Apple-Mail=_8935A690-5D2F-4271-AB81-E4E9D5D145BA-- From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 05:43:16 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A7ECD18; Fri, 17 Oct 2014 05:43:16 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64B56698; Fri, 17 Oct 2014 05:43:16 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id fp1so147869pdb.35 for ; Thu, 16 Oct 2014 22:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:importance:from:to:cc:mime-version :content-type; bh=RtUvPqQ96GgG9CKn3kosaimt6nlkFKIv3cKoP8g+w10=; b=ZLE1j3xrr/Ck6Nq30yEanYF71Nk24RgmUofNhMwstvdoGFb9urNq2/zdgl9MVZ0+Ao tp8f0zOzZvvK8iUGJkcrOXlmHbfIpFOKY3KW4caT91TehFBG5Q8YfCjf6pV7HX4E/NiE 1uzUF2y/T+jR32qm3RQkvRMZSLYYTYEJ/nxyh7NXXjJzmMjekR5hCxyW3IKraO1Z5L4g KAgqB5VqnUFmE1a2l/ztX/Z19oYmoeqBdYdjHYb1FyQfW+LIN+Lrhwz3kuQiRkA+Hn8F kUvkBgglQXfIlIzYimI6vxv8/Lp2ryz0wQNw5A/4SkV7+Le+rrC52u3+xLJN2PTgqyu8 Raiw== X-Received: by 10.66.102.105 with SMTP id fn9mr5929824pab.127.1413524595493; Thu, 16 Oct 2014 22:43:15 -0700 (PDT) Received: from ?IPv6:2602:306:c40e:720:ac6c:8a23:419a:6c00? ([2602:306:c40e:720:ac6c:8a23:419a:6c00]) by mx.google.com with ESMTPSA id c2sm393588pdl.14.2014.10.16.22.43.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 22:43:14 -0700 (PDT) Date: Thu, 16 Oct 2014 22:43:09 -0700 Subject: Re: Enabling VIMAGE by default for FreeBSD 11? Message-ID: Importance: normal From: "vijju.singh" To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , "Bjoern A. Zeeb" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 05:43:16 -0000 V2UndmUgc2VlbiBpc3N1ZXMgd2l0aCB2bmV0IGRlbGV0ZSBjYXVzaW5nIHN0YWxlIHBvaW50ZXJz IGluIG1idWZzIHJlZmVyZW5jaW5nIHRoZSBwZXItdm5ldCBsb29wYmFjayBpbnRlcmZhY2UgKGRl bGV0ZWQgd2l0aCB0aGUgdm5ldCkuCgoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR0FMQVhZIFPCrjQs IGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUKCjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogRGFnLUVybGluZyBTbcO4cmdyYXYgPGRlc0BkZXMu bm8+IDwvZGl2PjxkaXY+RGF0ZToxMC8xNi8yMDE0ICAxMDozOSBBTSAgKEdNVC0wODowMCkgPC9k aXY+PGRpdj5UbzogIkJqb2VybiBBLiBaZWViIiA8YnplZWItbGlzdHNAbGlzdHMuemFiYmFkb3ou bmV0PiA8L2Rpdj48ZGl2PkNjOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZyxmcmVlYnNkLXZpcnR1 YWxpemF0aW9uQGZyZWVic2Qub3JnLGZyZWVic2QtYXJjaCA8ZnJlZWJzZC1hcmNoQGZyZWVic2Qu b3JnPiA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBFbmFibGluZyBWSU1BR0UgYnkgZGVmYXVsdCBm b3IgRnJlZUJTRCAxMT8gPC9kaXY+PGRpdj4KPC9kaXY+IkJqb2VybiBBLiBaZWViIiA8YnplZWIt bGlzdHNAbGlzdHMuemFiYmFkb3oubmV0PiB3cml0ZXM6Cj4gRGFnLUVybGluZyBTbcO4cmdyYXYg PGRlc0BkZXMubm8+IHdyaXRlczoKPiA+IFRoZXJlIGFyZSBvdGhlciBzZXJpb3VzIGlzc3VlcyB3 aXRoIG91ciBjdXJyZW50IHBmIChjaGVja3N1bQo+ID4gY29ycnVwdGlvbikgd2hpY2ggSSB0aGlu ayBjYW4gb25seSBiZSByZXNvbHZlZCBieSBpbXBvcnRpbmcgYSBuZXdlcgo+ID4gdmVyc2lvbi4K PiBTb3JyeSwgYnV0IHlvdSBsb3N0IGNvbnRleHQuICBJIHdhcyB0YWxraW5nIGFib3V0IHNlY3Vy aXR5Cj4gaW1wbGljYXRpb25zIGluIFZJTUFHRSBjb250ZXh0LCBub3QgYWJvdXQgcmFuZG9tIGJ1 Z3MuCgpJIHJlYWxpemUgdGhhdCwgYnV0IHlvdSdyZSB0YWxraW5nIGFib3V0IHBhdGNoaW5nIG91 ciBjdXJyZW50IHBmLCBhbmQgSQp0aGluayB0aGF0J3MgYSB3YXN0ZSBvZiB0aW1lOyB3ZSBzaG91 bGQgaW1wb3J0IGEgbmV3ZXIgdmVyc2lvbiBpbnN0ZWFkCih3aGljaCBJIGFzc3VtZSBhbHJlYWR5 IGhhcyB0aG9zZSBwYXRjaGVzKS4KCkRFUwotLSAKRGFnLUVybGluZyBTbcO4cmdyYXYgLSBkZXNA ZGVzLm5vCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmZy ZWVic2QtYXJjaEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmZyZWVic2Qu b3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1hcmNoClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFu eSBtYWlsIHRvICJmcmVlYnNkLWFyY2gtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmci From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 05:48:49 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90C33EC9; Fri, 17 Oct 2014 05:48:49 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 61A976C5; Fri, 17 Oct 2014 05:48:48 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9H5mXa7042100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 22:48:37 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5440ADAB.6080308@freebsd.org> Date: Fri, 17 Oct 2014 13:48:27 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "vijju.singh" , =?UTF-8?B?RGFnLUVybGluZyBTbcO4?= =?UTF-8?B?cmdyYXY=?= , "Bjoern A. Zeeb" Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 05:48:49 -0000 On 10/17/14, 1:43 PM, vijju.singh wrote: > We've seen issues with vnet delete causing stale pointers in mbufs referencing the per-vnet loopback interface (deleted with the vnet). you can also see this sort of problem with removable devices. e.g. USB network interfaces, so it's not unique to vnet. > > Sent via the Samsung GALAXY S®4, an AT&T 4G LTE smartphone > >
-------- Original message --------
From: Dag-Erling Smørgrav
Date:10/16/2014 10:39 AM (GMT-08:00)
To: "Bjoern A. Zeeb"
Cc: freebsd-net@freebsd.org,freebsd-virtualization@freebsd.org,freebsd-arch
Subject: Re: Enabling VIMAGE by default for FreeBSD 11?
>
"Bjoern A. Zeeb" writes: >> Dag-Erling Smørgrav writes: >>> There are other serious issues with our current pf (checksum >>> corruption) which I think can only be resolved by importing a newer >>> version. >> Sorry, but you lost context. I was talking about security >> implications in VIMAGE context, not about random bugs. > I realize that, but you're talking about patching our current pf, and I > think that's a waste of time; we should import a newer version instead > (which I assume already has those patches). > > DES From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 07:53:10 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFAD131B; Fri, 17 Oct 2014 07:53:10 +0000 (UTC) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 551CE1FE; Fri, 17 Oct 2014 07:53:10 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id id10so204685vcb.20 for ; Fri, 17 Oct 2014 00:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qB4KzNXlawKqj9rptVBu63SM3xe6V731H/4TluOed8c=; b=p2E+wPdoFSmx7kM5sHmJy+e02DsYi3bVgis19FO8liQaaPrcBU09ZeVsmydhUfIAB3 93QkXFQ7Wd+5hN4G2msca1iTRs5X/CBCwdbq858m+QJq9862/q7IiAjGw9ptWQ2FE5KF JMkVQ9DIeCBUMISMuQ9AGqM4XTPgeuq3aPtLuNjnCuzz31O/4b22f8i44+Sik1RMN+fo wXFtpHVxnOOlk+6C54haM39iEDt30VDGKMGNpZ4Mg+P7Wo1EJ5hlWMx+YX7Yx+M5+3Zn 9VVli0CGUhoHagw1kRjDSLNx+QS70ofhG9KmbFLx6DnMQIXvLbQ3Oz49spjIQ3SntR6d m5SA== MIME-Version: 1.0 X-Received: by 10.52.248.76 with SMTP id yk12mr5039007vdc.1.1413532389208; Fri, 17 Oct 2014 00:53:09 -0700 (PDT) Sender: jlehen@gmail.com Received: by 10.31.136.79 with HTTP; Fri, 17 Oct 2014 00:53:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Oct 2014 09:53:09 +0200 X-Google-Sender-Auth: Fjzj8DsrxHejGbVpO08IiyysNHM Message-ID: Subject: Re: PIE/PIC support on base From: Jeremie Le Hen To: Shawn Webb Content-Type: text/plain; charset=UTF-8 Cc: hunger@hunger.hu, David Carlier , Oliver Pinter , Sean Bruno , Konstantin Belousov , freebsd-arch@freebsd.org, PaX Team , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 07:53:11 -0000 On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb wrote: > > > On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen wrote: >> >> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier >> wrote: >> > >> > I chose the "atomic" approach, at the moment very few binaries are >> > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the needed >> > libraries plus created WITH_PIE which add fPIE/fpie -pie flags only if >> > you >> > include (which include ...) otherwise >> > other >> > binaries include as usual hence does not apply. Look >> > reasonable approach ? >> >> I think I understand what you mean. But I think PIE is commonplace >> nowadays and I don't understand what you win by not enabling it for >> the whole system. Is it a performance concern? Is it to preserve >> conservative minds from to much change? :) > > > Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Bruno. > > On i386, there is a performance cost due to not having an extra register > available for the relocation work that has to happen. PIE doesn't carry much > of a performance penalty on amd64, though it still does carry some on first > resolution of functions (due to the extra relocation step the RTLD has to > worry about). On amd64, after symbol resolution has taken place, there is no > further performance penalty due to amd64 having an extra register to use for > PIE/PIC. I'm unsure what, if any, performance penalty PIE carries on ARM, > AArch64, and sparc64. > > Certain folk would prefer to see PIE enabled only in certain applications. > /bin/ls can't really make much use of PIE. But sshd can. I personally would > like to see all of base's applications compiled as PIEs, but that's a long > ways off. It took OpenBSD several years to accomplish that. Having certain > high-visibility applications (like sshd, inetd, etc) is a great start. > Providing a framework for application developers to opt their application > into PIE is another great start. > > Those are my two cents. OK. As long as i386 is still an important architecture, it can make sense to enable this on a per-binary basis if we don't want to have a discrepancy between archs. Also I buy your argument on /bin/ls but I was challenging to enable for the whole system because I wonder if there aren't some unexpected attack surfaces, besides the obvious ones (servers). Do you know what took so much time to OpenBSD? -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 08:05:14 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 283389AE; Fri, 17 Oct 2014 08:05:14 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EE10327; Fri, 17 Oct 2014 08:05:12 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so319786wgh.23 for ; Fri, 17 Oct 2014 01:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q/BzosFKREIc6Ojq+YgFUm5nEVbtLy53+mWv9qBKjBE=; b=PW8Nq1uic+gzG+1qItfNl6ZEfkRGZBkIGt09r7xEWIpdNffXqdlMcF5tyYZrWIknDo FHrsDhWgNQAQVVR6ccMvYWixh1pss9QKyE4uMl59cLn6+RrRQuBClEhAydVj5lAODIH8 1BFnMaxvnM2DAYvGdeDmcYzdrRfttaSy78lYNJQEu5ygt1M36mGBljexzmaJfaHXII4Q LQVRxUIE8lp/nF7aoZ4WQ0X0WL5WWlvtD623lApWtp2O5snzAgq3HGNKjlKM2/H5jy1p 2CzKV6bLVfUnureK0Qt3GNKqDrZxO+6Ix66mMWZ6Ri/soIpLHJRlKOPaSUClQvDotMcF A1Nw== MIME-Version: 1.0 X-Received: by 10.194.121.74 with SMTP id li10mr8219586wjb.40.1413533111457; Fri, 17 Oct 2014 01:05:11 -0700 (PDT) Received: by 10.216.141.6 with HTTP; Fri, 17 Oct 2014 01:05:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Oct 2014 04:05:11 -0400 Message-ID: Subject: Re: PIE/PIC support on base From: Shawn Webb To: Jeremie Le Hen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hunger@hunger.hu, David Carlier , Oliver Pinter , Sean Bruno , Konstantin Belousov , freebsd-arch@freebsd.org, PaX Team , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 08:05:14 -0000 On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen wrote: > On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb wrote: > > > > > > On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen wrote: > >> > >> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > >> wrote: > >> > > >> > I chose the "atomic" approach, at the moment very few binaries are > >> > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the > needed > >> > libraries plus created WITH_PIE which add fPIE/fpie -pie flags only if > >> > you > >> > include (which include ...) otherwise > >> > other > >> > binaries include as usual hence does not apply. Look > >> > reasonable approach ? > >> > >> I think I understand what you mean. But I think PIE is commonplace > >> nowadays and I don't understand what you win by not enabling it for > >> the whole system. Is it a performance concern? Is it to preserve > >> conservative minds from to much change? :) > > > > > > Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Bruno. > > > > On i386, there is a performance cost due to not having an extra register > > available for the relocation work that has to happen. PIE doesn't carry > much > > of a performance penalty on amd64, though it still does carry some on > first > > resolution of functions (due to the extra relocation step the RTLD has to > > worry about). On amd64, after symbol resolution has taken place, there > is no > > further performance penalty due to amd64 having an extra register to use > for > > PIE/PIC. I'm unsure what, if any, performance penalty PIE carries on ARM, > > AArch64, and sparc64. > > > > Certain folk would prefer to see PIE enabled only in certain > applications. > > /bin/ls can't really make much use of PIE. But sshd can. I personally > would > > like to see all of base's applications compiled as PIEs, but that's a > long > > ways off. It took OpenBSD several years to accomplish that. Having > certain > > high-visibility applications (like sshd, inetd, etc) is a great start. > > Providing a framework for application developers to opt their application > > into PIE is another great start. > > > > Those are my two cents. > > OK. As long as i386 is still an important architecture, it can make > sense to enable this on a per-binary basis if we don't want to have a > discrepancy between archs. Also I buy your argument on /bin/ls but I > was challenging to enable for the whole system because I wonder if > there aren't some unexpected attack surfaces, besides the obvious ones > (servers). > > Do you know what took so much time to OpenBSD? In a private conversation with Theo, I realized that my recollection of the time it took OpenBSD to compile all of base as PIEs was wrong. Quoting him: "It took 5 people approximately 3 months to debug it, activate it, and start shipping it the next release. That was on amd64, for all dynamically linked binaries, except one (a gcc bug took some time to find). The next architectures followed about 1 or 2 per 6-month release." Given that only one person has worked on this in the past (me) and now the task has been delegated to another (David Carlier), I think we're doing okay on our end. There's a lot of moving parts, and neither of us fully understand all of them completely. We're working on it in HardenedBSD, in the hardened/current/pie branch. I'm thinking we might try for a WITH_PIE knob (and *not* use USE_PIE) and have certain high-profile applications opt-in to PIE until we work out all the details for everything en masse. Baptiste did bring up a good point with INTERNALLIB and I'm unsure of how we should handle that. Any guidance is appreciated. We'll continue on the route we're currently going unless we have guidance to suggest otherwise. Thanks, Shawn From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 11:37:48 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33C55BE6; Fri, 17 Oct 2014 11:37:48 +0000 (UTC) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B21A7B22; Fri, 17 Oct 2014 11:37:47 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.9/8.14.9/ALCHEMY.FRANKEN.DE) with ESMTP id s9HBbcxK016782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Oct 2014 13:37:38 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.9/8.14.9/Submit) id s9HBbbb6016781; Fri, 17 Oct 2014 13:37:37 +0200 (CEST) (envelope-from marius) Date: Fri, 17 Oct 2014 13:37:37 +0200 From: Marius Strobl To: Craig Rodrigues Subject: Re: Enabling VIMAGE by default for FreeBSD 11? Message-ID: <20141017113737.GA16736@alchemy.franken.de> References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Fri, 17 Oct 2014 13:37:38 +0200 (CEST) Cc: FreeBSD Net , Adrian Chadd , freebsd-arch , "freebsd-virtualization@freebsd.org" , Kris Moore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 11:37:48 -0000 On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote: > On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: > > > > > It was for a while in 9.2, but we removed it from 10.0 and later due to > > stability issues we kept getting reports about. Haven't tried it since > > then, dont know if those issues are fixed. > > > > I fixed some of the problems with VIMAGE that I encountered with Bluetooth: > > https://lists.freebsd.org/pipermail/svn-src-head/2013-July/049582.html ... which still lacks a proper implementation that doesn't constitute a gross layering violation in generic bus code. > > Hiroo Onoo submitted this patch, which I committed to fix problems with > VIMAGE encountered with removable USB Ethernet: > > https://lists.freebsd.org/pipermail/svn-src-all/2014-February/081025.html > > Martin Matuska committed this fix for PF: > https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html > > So a lot of the stability problems with VIMAGE which were in PC-BSD 9.2 and > FreeBSD 9.x have been slowly been fixed. Marius From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 11:52:35 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24BA51B9; Fri, 17 Oct 2014 11:52:35 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6C42CDF; Fri, 17 Oct 2014 11:52:33 +0000 (UTC) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 17 Oct 2014 13:51:21 +0200 Date: Fri, 17 Oct 2014 13:51:42 +0200 From: Marko Zec To: Marius Strobl Subject: Re: Enabling VIMAGE by default for FreeBSD 11? Message-ID: <20141017135142.3f5a713c@x23> In-Reply-To: <20141017113737.GA16736@alchemy.franken.de> References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> <20141017113737.GA16736@alchemy.franken.de> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [161.53.63.210] Cc: Craig Rodrigues , Adrian Chadd , "freebsd-virtualization@freebsd.org" , FreeBSD Net , freebsd-arch , Kris Moore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 11:52:35 -0000 On Fri, 17 Oct 2014 13:37:37 +0200 Marius Strobl wrote: > On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote: > > On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: > > > > > > > > It was for a while in 9.2, but we removed it from 10.0 and later > > > due to stability issues we kept getting reports about. Haven't > > > tried it since then, dont know if those issues are fixed. > > > > > > > I fixed some of the problems with VIMAGE that I encountered with > > Bluetooth: > > > > https://lists.freebsd.org/pipermail/svn-src-head/2013-July/049582.html > > ... which still lacks a proper implementation that doesn't constitute > a gross layering violation in generic bus code. By all means please go ahead and propose a layering-clean alternative, not as ugly and intrusive as this part which I assume bodes you eyes: - return (device_attach(dev)); + + CURVNET_SET_QUIET(vnet0); + error = device_attach(dev); + CURVNET_RESTORE(); + return error; Marko > > > > Hiroo Onoo submitted this patch, which I committed to fix problems > > with VIMAGE encountered with removable USB Ethernet: > > > > https://lists.freebsd.org/pipermail/svn-src-all/2014-February/081025.html > > > > Martin Matuska committed this fix for PF: > > https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html > > > > So a lot of the stability problems with VIMAGE which were in PC-BSD > > 9.2 and FreeBSD 9.x have been slowly been fixed. > > Marius > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 13:12:08 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D6CB1B0; Fri, 17 Oct 2014 13:12:08 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2017F690; Fri, 17 Oct 2014 13:12:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9HDC0jw003249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 16:12:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9HDC0jw003249 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9HDC02G003248; Fri, 17 Oct 2014 16:12:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 17 Oct 2014 16:12:00 +0300 From: Konstantin Belousov To: Shawn Webb Subject: Re: PIE/PIC support on base Message-ID: <20141017131159.GD2153@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hunger@hunger.hu, David Carlier , Oliver Pinter , PaX Team , Sean Bruno , freebsd-arch@freebsd.org, Jeremie Le Hen , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:12:08 -0000 On Thu, Oct 16, 2014 at 06:15:38PM -0400, Shawn Webb wrote: > On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen wrote: > > > On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > > wrote: > > > > > > I chose the "atomic" approach, at the moment very few binaries are > > > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the needed > > > libraries plus created WITH_PIE which add fPIE/fpie -pie flags only if > > you > > > include (which include ...) otherwise > > other > > > binaries include as usual hence does not apply. Look > > > reasonable approach ? > > > > I think I understand what you mean. But I think PIE is commonplace > > nowadays and I don't understand what you win by not enabling it for > > the whole system. Is it a performance concern? Is it to preserve > > conservative minds from to much change? :) > > > Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Bruno. > > On i386, there is a performance cost due to not having an extra register > available for the relocation work that has to happen. PIE doesn't carry > much of a performance penalty on amd64, though it still does carry some on > first resolution of functions (due to the extra relocation step the RTLD > has to worry about). On amd64, after symbol resolution has taken place, > there is no further performance penalty due to amd64 having an extra > register to use for PIE/PIC. I'm unsure what, if any, performance penalty > PIE carries on ARM, AArch64, and sparc64. -fPIE generates PIC code, in particular, the main binary symbols are resolved through GOT (and functions are called through PLT). This is additional level of indirection, which causes additional memory access outside of the instruction stream reads. Also, for the same reason, PIE changes ELF rules for the symbol resolution. In particular, symbols from the main binary appear in the dynamic symbol table, and are the subject of interposing. > > Certain folk would prefer to see PIE enabled only in certain applications. > /bin/ls can't really make much use of PIE. But sshd can. I personally would > like to see all of base's applications compiled as PIEs, but that's a long > ways off. It took OpenBSD several years to accomplish that. Having certain > high-visibility applications (like sshd, inetd, etc) is a great start. > Providing a framework for application developers to opt their application > into PIE is another great start. Exercise for certain folks: how does dynamic loading of the PAM modules interacts with PIE ? Hint: see above about dynamic symbols and interposing. > > Those are my two cents. > > Thanks, > > Shawn From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 13:41:28 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 529F98FD for ; Fri, 17 Oct 2014 13:41:28 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E348978 for ; Fri, 17 Oct 2014 13:41:27 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id h18so1584921igc.6 for ; Fri, 17 Oct 2014 06:41:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=e2j6houDoBR3t4NsYkb8Aose+yaAcJOd2vR9LcdDCPs=; b=UWcQHFNs7X60xDnmDjd4sfdUmQhMrQcE63JxW5B5tVi9vhqvEs8iOKSGa3XhYvPuV6 /ZFN4VTKJ2QcP0vh1sQP6lu7Ry5DDrLP04NvOuMVvSUtqfK6cPRyp+PlN85I6M4Q1Jma Ms7DYWbSdsNfIyp18J4Win993VwrqdSzQhNKNZ5AoEhHf9yi4RXEFiFSNqZ3UiOX0LwL 2WU9kZROzIF2wUBL4OBpCUTR8pQpMW+t8/07ASPSk2E7B8v7xNvqbKBgNBAPQp/PURyr Eiwmw2B98JCjm9jMYqhaaMG7ti9alm0r+pKZJ8HpPDxpAWIS7a3oFqmV/ohNHt/FR2IC auRA== X-Gm-Message-State: ALoCoQlOLYKTXFP98ZTsSeNQUNS03dkDysngZZGWmPxVep3oUFVeZYeirQpWdDO73CsYAJv+vpVi X-Received: by 10.107.3.25 with SMTP id 25mr2363858iod.69.1413553286536; Fri, 17 Oct 2014 06:41:26 -0700 (PDT) Received: from bsdimp.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id o62sm656572ioe.12.2014.10.17.06.41.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 06:41:25 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_C9A81F84-205F-4468-B0E6-6F6B44558AF7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: PIE/PIC support on base From: Warner Losh In-Reply-To: Date: Fri, 17 Oct 2014 07:41:22 -0600 Message-Id: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> References: To: Shawn Webb X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Fri, 17 Oct 2014 13:46:26 +0000 Cc: hunger@hunger.hu, David Carlier , Oliver Pinter , PaX Team , Sean Bruno , Konstantin Belousov , FreeBSD Arch , Jeremie Le Hen , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:41:28 -0000 --Apple-Mail=_C9A81F84-205F-4468-B0E6-6F6B44558AF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen = wrote: >=20 >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb = wrote: >>>=20 >>>=20 >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen = wrote: >>>>=20 >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier >>>> wrote: >>>>>=20 >>>>> I chose the "atomic" approach, at the moment very few binaries are >>>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the >> needed >>>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flags = only if >>>>> you >>>>> include (which include ...) = otherwise >>>>> other >>>>> binaries include as usual hence does not apply. Look >>>>> reasonable approach ? >>>>=20 >>>> I think I understand what you mean. But I think PIE is commonplace >>>> nowadays and I don't understand what you win by not enabling it for >>>> the whole system. Is it a performance concern? Is it to preserve >>>> conservative minds from to much change? :) >>>=20 >>>=20 >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean = Bruno. >>>=20 >>> On i386, there is a performance cost due to not having an extra = register >>> available for the relocation work that has to happen. PIE doesn't = carry >> much >>> of a performance penalty on amd64, though it still does carry some = on >> first >>> resolution of functions (due to the extra relocation step the RTLD = has to >>> worry about). On amd64, after symbol resolution has taken place, = there >> is no >>> further performance penalty due to amd64 having an extra register to = use >> for >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carries on = ARM, >>> AArch64, and sparc64. >>>=20 >>> Certain folk would prefer to see PIE enabled only in certain >> applications. >>> /bin/ls can't really make much use of PIE. But sshd can. I = personally >> would >>> like to see all of base's applications compiled as PIEs, but that's = a >> long >>> ways off. It took OpenBSD several years to accomplish that. Having >> certain >>> high-visibility applications (like sshd, inetd, etc) is a great = start. >>> Providing a framework for application developers to opt their = application >>> into PIE is another great start. >>>=20 >>> Those are my two cents. >>=20 >> OK. As long as i386 is still an important architecture, it can make >> sense to enable this on a per-binary basis if we don't want to have a >> discrepancy between archs. Also I buy your argument on /bin/ls but I >> was challenging to enable for the whole system because I wonder if >> there aren't some unexpected attack surfaces, besides the obvious = ones >> (servers). >>=20 >> Do you know what took so much time to OpenBSD? >=20 >=20 > In a private conversation with Theo, I realized that my recollection = of the > time it took OpenBSD to compile all of base as PIEs was wrong. Quoting = him: >=20 > "It took 5 people approximately 3 months to debug it, activate it, and > start shipping it the next release. That was on amd64, for all > dynamically linked binaries, except one (a gcc bug took some time to > find). The next architectures followed about 1 or 2 per 6-month > release." >=20 > Given that only one person has worked on this in the past (me) and now = the > task has been delegated to another (David Carlier), I think we're = doing > okay on our end. There's a lot of moving parts, and neither of us = fully > understand all of them completely. We're working on it in HardenedBSD, = in > the hardened/current/pie branch. >=20 > I'm thinking we might try for a WITH_PIE knob (and *not* use USE_PIE) = and > have certain high-profile applications opt-in to PIE until we work out = all > the details for everything en masse. Baptiste did bring up a good = point > with INTERNALLIB and I'm unsure of how we should handle that. WITH_PIE or WITHOUT_PIE controls, on a global basis, via the MK_PIE variable, whether or not the user wants to turn on this feature for = those program that can do PIE. Designating which programs do, or don=92t, use PIE simply must be done with a different variable. I posted a bit of = a rant about the current state of things that suggested a couple of alternatives as well as giving some history as to why some options aren=92t to be used and the history behind some of my reactions. :) For this reason, I think WITH_PIE, as I understand your proposal, likely isn=92t a good fit with other WITH_xxx variables used in the src tree today. Warner --Apple-Mail=_C9A81F84-205F-4468-B0E6-6F6B44558AF7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQRyCAAoJEGwc0Sh9sBEAW7EQAKo+M1fXOG9+zpjbGsMMre+B T2q1Rmo5mUeXjrAX1s7dyraXp39O5XfnCDIQJj82pFF90L1M0kB8wm4trU9QDYEL rhAnVN/ajLYJ8Q89CwhWaW9di08VvciKLfJ3fLPjH3p+NqWBcuY46yiwAzsGpBL0 SDHMS148jW5xAkg2JAGuepanjQeVfjJZUIMO6i/f2jZVUfmupkpl8AqRp+cQiziC ALoxfc3bn1mD8ECXenQFiDzMmAN4fpN4gVaPGvM7YHfaDiEDJVlgJbK3iJqvHdBC vLM4/tvw1DhqF0cJ1drcGEAwafDNILEsCpMdNqzZ+UU5GuD9FG1DO0QyjFUtP8// P50O74Pw6v/oFVQWvwaUqzcQ39txsBgaBcevoO22GgQwwVTx+xX0tIpBDb2jJpnv JgrvjHoDMPePM7r44SaPQgPkntbVGbpjlNmL1o7jSBahkdkWHdkqqOmYZkk+MQ+C RPwB09CyQwavvqFI2NZ7w1FqOiguK0WeQG5VhYTcSzQJQTiv7EBLoikcw+HxkU7Y rEI69poq+zuL7fN7RFibxKnJt30eTXhuvI05/cn9cjZZW/7Uc1KY1FQ1DJTRnqS8 4fW8qhItoena+UXPjtlIUAIQa9HEc4OkgXM8unaEquBoli3RwxUa5xq6fwr6AmIz eOghcbHwfhbgM0R+YwA6 =cajQ -----END PGP SIGNATURE----- --Apple-Mail=_C9A81F84-205F-4468-B0E6-6F6B44558AF7-- From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 14:06:06 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1DF35BB for ; Fri, 17 Oct 2014 14:06:06 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0E68BBF for ; Fri, 17 Oct 2014 14:06:06 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rd18so811292iec.1 for ; Fri, 17 Oct 2014 07:06:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=tXHMC0Fnbqz7ZiBIXKwHMFjJnCNSpr7ARW6NhZuFdbk=; b=DuRa9jTAoWM7kM4649TMcP9CPgD1hBUy7+4uEP5tNTHThIMIbSCP9z1tH/+1ptvJNs cGBA5Bcq7RXXUbOkFpN1GHrHHC4UXk3jw0eI1EaRtHwG9QkD2HRWH+nyGxdoWqGPI4Gm FNL5HbYi0lHEWTJm0Qa9TtP6sc5gaKeD9yoSptkbtCordUZ7S60lhX5eF7ZEbjYnCCc8 dQKI3knDWzt2ao66RO4DvAGBwmHr3P78PTfAsGn/MeAQSZS6s0B+DhVR6oKwC9wovx1R bkZZHriY3cVQsdbxY+yFCIuyzv7A5+mFEU8Ga4pTG/InZdCRxVMVzO4By1iffPpnpQLo /2rw== X-Gm-Message-State: ALoCoQlOCvOdvMvI/CZtwsKLUZc3+HHgk6wOESd25LQFeDIpEJSyccKpqv4gLk+DkAQ+uMmjaIua X-Received: by 10.50.111.132 with SMTP id ii4mr12661582igb.39.1413554760437; Fri, 17 Oct 2014 07:06:00 -0700 (PDT) Received: from bsdimp.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id o101sm678056ioi.20.2014.10.17.07.05.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 07:05:59 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_F6EE233D-E5F0-4992-82A3-B31CF2F911A4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: PIE/PIC support on base From: Warner Losh In-Reply-To: Date: Fri, 17 Oct 2014 08:05:57 -0600 Message-Id: References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> To: Shawn Webb X-Mailer: Apple Mail (2.1878.6) Cc: PaX Team , FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:06:07 -0000 --Apple-Mail=_F6EE233D-E5F0-4992-82A3-B31CF2F911A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 [[cc trimmed ]] On Oct 17, 2014, at 7:46 AM, Shawn Webb wrote: > On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh wrote: >=20 > On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: >=20 > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen = wrote: > > > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb = wrote: > >>> > >>> > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen = wrote: > >>>> > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > >>>> wrote: > >>>>> > >>>>> I chose the "atomic" approach, at the moment very few binaries = are > >>>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the > >> needed > >>>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flags = only if > >>>>> you > >>>>> include (which include ...) = otherwise > >>>>> other > >>>>> binaries include as usual hence does not apply. = Look > >>>>> reasonable approach ? > >>>> > >>>> I think I understand what you mean. But I think PIE is = commonplace > >>>> nowadays and I don't understand what you win by not enabling it = for > >>>> the whole system. Is it a performance concern? Is it to = preserve > >>>> conservative minds from to much change? :) > >>> > >>> > >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean = Bruno. > >>> > >>> On i386, there is a performance cost due to not having an extra = register > >>> available for the relocation work that has to happen. PIE doesn't = carry > >> much > >>> of a performance penalty on amd64, though it still does carry some = on > >> first > >>> resolution of functions (due to the extra relocation step the RTLD = has to > >>> worry about). On amd64, after symbol resolution has taken place, = there > >> is no > >>> further performance penalty due to amd64 having an extra register = to use > >> for > >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carries = on ARM, > >>> AArch64, and sparc64. > >>> > >>> Certain folk would prefer to see PIE enabled only in certain > >> applications. > >>> /bin/ls can't really make much use of PIE. But sshd can. I = personally > >> would > >>> like to see all of base's applications compiled as PIEs, but = that's a > >> long > >>> ways off. It took OpenBSD several years to accomplish that. Having > >> certain > >>> high-visibility applications (like sshd, inetd, etc) is a great = start. > >>> Providing a framework for application developers to opt their = application > >>> into PIE is another great start. > >>> > >>> Those are my two cents. > >> > >> OK. As long as i386 is still an important architecture, it can = make > >> sense to enable this on a per-binary basis if we don't want to have = a > >> discrepancy between archs. Also I buy your argument on /bin/ls but = I > >> was challenging to enable for the whole system because I wonder if > >> there aren't some unexpected attack surfaces, besides the obvious = ones > >> (servers). > >> > >> Do you know what took so much time to OpenBSD? > > > > > > In a private conversation with Theo, I realized that my recollection = of the > > time it took OpenBSD to compile all of base as PIEs was wrong. = Quoting him: > > > > "It took 5 people approximately 3 months to debug it, activate it, = and > > start shipping it the next release. That was on amd64, for all > > dynamically linked binaries, except one (a gcc bug took some time to > > find). The next architectures followed about 1 or 2 per 6-month > > release." > > > > Given that only one person has worked on this in the past (me) and = now the > > task has been delegated to another (David Carlier), I think we're = doing > > okay on our end. There's a lot of moving parts, and neither of us = fully > > understand all of them completely. We're working on it in = HardenedBSD, in > > the hardened/current/pie branch. > > > > I'm thinking we might try for a WITH_PIE knob (and *not* use = USE_PIE) and > > have certain high-profile applications opt-in to PIE until we work = out all > > the details for everything en masse. Baptiste did bring up a good = point > > with INTERNALLIB and I'm unsure of how we should handle that. >=20 > WITH_PIE or WITHOUT_PIE controls, on a global basis, via the MK_PIE > variable, whether or not the user wants to turn on this feature for = those > program that can do PIE. Designating which programs do, or don=92t, > use PIE simply must be done with a different variable. I posted a bit = of a > rant about the current state of things that suggested a couple of > alternatives as well as giving some history as to why some options > aren=92t to be used and the history behind some of my reactions. :) >=20 > For this reason, I think WITH_PIE, as I understand your proposal, > likely isn=92t a good fit with other WITH_xxx variables used in the = src > tree today. >=20 > Gotcha. To be honest, I found your email a tad bit confusing. Are you = suggesting we create an ENABLE_feature framework? Or are you suggesting = we have a USE_PIE flag? Or are you suggesting something different = entirely (and if you are, what?)? I=92m saying we don=92t have a good framework at the moment to do this. = We have several bad ones that all have their pitfalls. This is one reason I = had the fast reaction to NO_PIE, then a minute later said =93go ahead and = use it and I=92ll fix it.=94 I=92m still cool with that position, btw. As for a name, that can be debated a lot, but I=92d like to see = something new, easy to use and unambiguous. If you are looking for a suggestion for that name, let=92s go with WANTS_PIE. Only Makefiles can set it. WANTS_PIE undefined means do the default behavior as defined by the current MK_PIE setting and perhaps system policy. =93Go with this flow." WANTS_PIE=3Dyes means that if MK_PIE is =93yes=94, then do PIE things = for this thing we=92re building. If MK_PIE is =93no=94, though PIE is = disabled for everything. WANTS_PIE=3Dno means that if MK_PIE is =93yes=94, then disable doing PIE things for this component. If MK_PIE is no, it is also disabled. This could also be extended to NEEDS_foo, which says =93I need foo to build, and if MK_foo is set to no, don=92t build me.=94 I don=92t think = anything that you are doing falls into this category though. WANTS/NEEDS also avoids the historical use of USE in the ports tree possibly creating confusion.=20 If you go with WANTS_PIE, then you wouldn=92t need bad.*.pie.mk. Comments? Warner --Apple-Mail=_F6EE233D-E5F0-4992-82A3-B31CF2F911A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQSJFAAoJEGwc0Sh9sBEAZA0QANkEzzPHyDL5PhCwzBSA0jhO dJz2z9fbcFavg13uEuabUvIHBq4XX7tqc1k4hCsIlrjK/alsyizBjvATut5wyyNJ OnMY+rg5zfM2Bj5ujuV2NtUlhKoYC0Gw5YQGwNl5T+7OCDOh0QUJCjGP1I2M4ScP HQSkT5byusQoOKJmQnC/JRBD6jxKXzVfQ9ea1Yy/PtuVXjIT95tSOxFW+t/rVWP/ kpPgNGDr7n06HG3gRldJC8P8HTB76ElheM73nELwzHf3D0ZkRwyhbvHoeVQSqQUY sI2d3PY9wV7ITMlhTNvkOGs/TA3jhwNDDbXDWg2I3UgVkvMixbd+um7r4MZrPbrd jiY/q3cF3Wbf5MFlTnqWqB7nM0e1dcjG21fCh1yk1z8Q2k9PRVmnKmb8Wl/7G96S NenRpFKEcWQp4AKLOrV2kAGRYYn753FLiLzqF+SHzl1fVFdWoXUDSscvbv86MyJn ufERZ4E6aXY+HLYQz6Uquq5QeAm3TgsRDlhzfkXqb4EKZi6p8S1yjPH77inMet9H FIxJFQQRpoYwij3XMjZW6wgKQbT4+Liah442mSSmM03WgItidTAArBXYzq/uGokJ oTpLcZX5FhM9pVS0RL4LSyvU6J4lK1nllbPQhaOZyjVZf81eQZXoOkKwWSB0cXHM JuhAcjKQqK0dHe1kFeyo =P4l5 -----END PGP SIGNATURE----- --Apple-Mail=_F6EE233D-E5F0-4992-82A3-B31CF2F911A4-- From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 13:46:31 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7985FAE; Fri, 17 Oct 2014 13:46:31 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B78259CA; Fri, 17 Oct 2014 13:46:30 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id em10so1302587wid.7 for ; Fri, 17 Oct 2014 06:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=00tCZSmwvPNhokrwey39VzYEqXhGrtao4vx/BiZg6aw=; b=YXTlJiPie5fUoEgXJZ1JSOAe/l5EMMtnbeU1em8UnSz3UgCZ52RuYibXgjDDen/a2Y n3QbSvG1njm7lISKQfP0v11SI2exM7sYB16p6RKLsMFL5SrJF/AYSVXnf6ITix4QdN7J /yx9BK6NHkRMmRdt1lZ2hMr/1wmioYj78jM89pPcrRgYLnPxg+h2ay9NEu5qK6eAhggl IOGI5i9ilSaGfizOpfQCWmg90fJG9OCzvt9xG7hXQH8Wrzlevl0ATY6NXrr73gY66RvQ XTTksFD4V12fa64kr3U/Hfk/S7SkcYpN1VC/y2gxZBjtXdUzEdsrt9aeHFTzMDp8cSAU 6Jsg== MIME-Version: 1.0 X-Received: by 10.194.121.74 with SMTP id li10mr10336788wjb.40.1413553587771; Fri, 17 Oct 2014 06:46:27 -0700 (PDT) Received: by 10.216.141.6 with HTTP; Fri, 17 Oct 2014 06:46:27 -0700 (PDT) In-Reply-To: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> Date: Fri, 17 Oct 2014 09:46:27 -0400 Message-ID: Subject: Re: PIE/PIC support on base From: Shawn Webb To: Warner Losh X-Mailman-Approved-At: Fri, 17 Oct 2014 14:07:30 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hunger@hunger.hu, David Carlier , Oliver Pinter , PaX Team , Sean Bruno , Konstantin Belousov , FreeBSD Arch , Jeremie Le Hen , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:46:32 -0000 On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh wrote: > > On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: > > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen wrote= : > > > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb wrote= : > >>> > >>> > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen > wrote: > >>>> > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > >>>> wrote: > >>>>> > >>>>> I chose the "atomic" approach, at the moment very few binaries are > >>>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the > >> needed > >>>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flags only > if > >>>>> you > >>>>> include (which include ...) otherwis= e > >>>>> other > >>>>> binaries include as usual hence does not apply. Look > >>>>> reasonable approach ? > >>>> > >>>> I think I understand what you mean. But I think PIE is commonplace > >>>> nowadays and I don't understand what you win by not enabling it for > >>>> the whole system. Is it a performance concern? Is it to preserve > >>>> conservative minds from to much change? :) > >>> > >>> > >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Brun= o. > >>> > >>> On i386, there is a performance cost due to not having an extra > register > >>> available for the relocation work that has to happen. PIE doesn't car= ry > >> much > >>> of a performance penalty on amd64, though it still does carry some on > >> first > >>> resolution of functions (due to the extra relocation step the RTLD ha= s > to > >>> worry about). On amd64, after symbol resolution has taken place, ther= e > >> is no > >>> further performance penalty due to amd64 having an extra register to > use > >> for > >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carries on > ARM, > >>> AArch64, and sparc64. > >>> > >>> Certain folk would prefer to see PIE enabled only in certain > >> applications. > >>> /bin/ls can't really make much use of PIE. But sshd can. I personally > >> would > >>> like to see all of base's applications compiled as PIEs, but that's a > >> long > >>> ways off. It took OpenBSD several years to accomplish that. Having > >> certain > >>> high-visibility applications (like sshd, inetd, etc) is a great start= . > >>> Providing a framework for application developers to opt their > application > >>> into PIE is another great start. > >>> > >>> Those are my two cents. > >> > >> OK. As long as i386 is still an important architecture, it can make > >> sense to enable this on a per-binary basis if we don't want to have a > >> discrepancy between archs. Also I buy your argument on /bin/ls but I > >> was challenging to enable for the whole system because I wonder if > >> there aren't some unexpected attack surfaces, besides the obvious ones > >> (servers). > >> > >> Do you know what took so much time to OpenBSD? > > > > > > In a private conversation with Theo, I realized that my recollection of > the > > time it took OpenBSD to compile all of base as PIEs was wrong. Quoting > him: > > > > "It took 5 people approximately 3 months to debug it, activate it, and > > start shipping it the next release. That was on amd64, for all > > dynamically linked binaries, except one (a gcc bug took some time to > > find). The next architectures followed about 1 or 2 per 6-month > > release." > > > > Given that only one person has worked on this in the past (me) and now > the > > task has been delegated to another (David Carlier), I think we're doing > > okay on our end. There's a lot of moving parts, and neither of us fully > > understand all of them completely. We're working on it in HardenedBSD, = in > > the hardened/current/pie branch. > > > > I'm thinking we might try for a WITH_PIE knob (and *not* use USE_PIE) a= nd > > have certain high-profile applications opt-in to PIE until we work out > all > > the details for everything en masse. Baptiste did bring up a good point > > with INTERNALLIB and I'm unsure of how we should handle that. > > WITH_PIE or WITHOUT_PIE controls, on a global basis, via the MK_PIE > variable, whether or not the user wants to turn on this feature for those > program that can do PIE. Designating which programs do, or don=E2=80=99t, > use PIE simply must be done with a different variable. I posted a bit of = a > rant about the current state of things that suggested a couple of > alternatives as well as giving some history as to why some options > aren=E2=80=99t to be used and the history behind some of my reactions. :) > > For this reason, I think WITH_PIE, as I understand your proposal, > likely isn=E2=80=99t a good fit with other WITH_xxx variables used in the= src > tree today. Gotcha. To be honest, I found your email a tad bit confusing. Are you suggesting we create an ENABLE_feature framework? Or are you suggesting we have a USE_PIE flag? Or are you suggesting something different entirely (and if you are, what?)? Thanks, Shawn From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 14:10:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E707C824 for ; Fri, 17 Oct 2014 14:10:17 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BC53C7D for ; Fri, 17 Oct 2014 14:10:17 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id b13so1004044wgh.0 for ; Fri, 17 Oct 2014 07:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ox/IiWXXb0IMPaqKqrba50RiljeUYzPNYl2H6cjqACU=; b=mVBlI/DmjxL7/5+2rIOdx2t0/okTTbCawnaH6tsFnvsaK1J8Ilk94stBBx5V+s/5Rn 14WNLGaU1BPsUTnMboPsqXmZ7mtL2l5dUvyLatDRiqMBSKwQyS42UDlpkNdAcokw81T4 ieReRtV8HNmglbwz+rgHvieeb33WA79JNv753pwd/ECeyCN2deF8HKirEw3wUm5ihEOk swRkdBb/Jx/GcGWY2pSIUa3gDNYvHSF61Bh+ymHAPc5irQKsthyWUD2CXthdu+fvTqu4 JRE6vt8vkQPo+aY1WRYBSVXoLeXvDMeYmgaMVqjh7d/Ysm1Z4fAcQYNFOGPzo3creTAz 8rug== MIME-Version: 1.0 X-Received: by 10.180.100.106 with SMTP id ex10mr29435183wib.63.1413555015602; Fri, 17 Oct 2014 07:10:15 -0700 (PDT) Received: by 10.216.141.6 with HTTP; Fri, 17 Oct 2014 07:10:15 -0700 (PDT) In-Reply-To: References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> Date: Fri, 17 Oct 2014 10:10:15 -0400 Message-ID: Subject: Re: PIE/PIC support on base From: Shawn Webb To: Warner Losh , David Carlier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: PaX Team , FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:10:18 -0000 On Fri, Oct 17, 2014 at 10:05 AM, Warner Losh wrote: > [[cc trimmed ]] > > On Oct 17, 2014, at 7:46 AM, Shawn Webb wrote: > > > On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh wrote: > > > > On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: > > > > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen > wrote: > > > > > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb > wrote: > > >>> > > >>> > > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen > wrote: > > >>>> > > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > > >>>> wrote: > > >>>>> > > >>>>> I chose the "atomic" approach, at the moment very few binaries ar= e > > >>>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the > > >> needed > > >>>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flags > only if > > >>>>> you > > >>>>> include (which include ...) > otherwise > > >>>>> other > > >>>>> binaries include as usual hence does not apply. Loo= k > > >>>>> reasonable approach ? > > >>>> > > >>>> I think I understand what you mean. But I think PIE is commonplac= e > > >>>> nowadays and I don't understand what you win by not enabling it fo= r > > >>>> the whole system. Is it a performance concern? Is it to preserve > > >>>> conservative minds from to much change? :) > > >>> > > >>> > > >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean > Bruno. > > >>> > > >>> On i386, there is a performance cost due to not having an extra > register > > >>> available for the relocation work that has to happen. PIE doesn't > carry > > >> much > > >>> of a performance penalty on amd64, though it still does carry some = on > > >> first > > >>> resolution of functions (due to the extra relocation step the RTLD > has to > > >>> worry about). On amd64, after symbol resolution has taken place, > there > > >> is no > > >>> further performance penalty due to amd64 having an extra register t= o > use > > >> for > > >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carries o= n > ARM, > > >>> AArch64, and sparc64. > > >>> > > >>> Certain folk would prefer to see PIE enabled only in certain > > >> applications. > > >>> /bin/ls can't really make much use of PIE. But sshd can. I personal= ly > > >> would > > >>> like to see all of base's applications compiled as PIEs, but that's= a > > >> long > > >>> ways off. It took OpenBSD several years to accomplish that. Having > > >> certain > > >>> high-visibility applications (like sshd, inetd, etc) is a great > start. > > >>> Providing a framework for application developers to opt their > application > > >>> into PIE is another great start. > > >>> > > >>> Those are my two cents. > > >> > > >> OK. As long as i386 is still an important architecture, it can make > > >> sense to enable this on a per-binary basis if we don't want to have = a > > >> discrepancy between archs. Also I buy your argument on /bin/ls but I > > >> was challenging to enable for the whole system because I wonder if > > >> there aren't some unexpected attack surfaces, besides the obvious on= es > > >> (servers). > > >> > > >> Do you know what took so much time to OpenBSD? > > > > > > > > > In a private conversation with Theo, I realized that my recollection > of the > > > time it took OpenBSD to compile all of base as PIEs was wrong. Quotin= g > him: > > > > > > "It took 5 people approximately 3 months to debug it, activate it, an= d > > > start shipping it the next release. That was on amd64, for all > > > dynamically linked binaries, except one (a gcc bug took some time to > > > find). The next architectures followed about 1 or 2 per 6-month > > > release." > > > > > > Given that only one person has worked on this in the past (me) and no= w > the > > > task has been delegated to another (David Carlier), I think we're doi= ng > > > okay on our end. There's a lot of moving parts, and neither of us ful= ly > > > understand all of them completely. We're working on it in HardenedBSD= , > in > > > the hardened/current/pie branch. > > > > > > I'm thinking we might try for a WITH_PIE knob (and *not* use USE_PIE) > and > > > have certain high-profile applications opt-in to PIE until we work ou= t > all > > > the details for everything en masse. Baptiste did bring up a good poi= nt > > > with INTERNALLIB and I'm unsure of how we should handle that. > > > > WITH_PIE or WITHOUT_PIE controls, on a global basis, via the MK_PIE > > variable, whether or not the user wants to turn on this feature for tho= se > > program that can do PIE. Designating which programs do, or don=E2=80=99= t, > > use PIE simply must be done with a different variable. I posted a bit o= f > a > > rant about the current state of things that suggested a couple of > > alternatives as well as giving some history as to why some options > > aren=E2=80=99t to be used and the history behind some of my reactions. = :) > > > > For this reason, I think WITH_PIE, as I understand your proposal, > > likely isn=E2=80=99t a good fit with other WITH_xxx variables used in t= he src > > tree today. > > > > Gotcha. To be honest, I found your email a tad bit confusing. Are you > suggesting we create an ENABLE_feature framework? Or are you suggesting w= e > have a USE_PIE flag? Or are you suggesting something different entirely > (and if you are, what?)? > > I=E2=80=99m saying we don=E2=80=99t have a good framework at the moment t= o do this. We > have several bad ones that all have their pitfalls. This is one reason I > had > the fast reaction to NO_PIE, then a minute later said =E2=80=9Cgo ahead a= nd use > it and I=E2=80=99ll fix it.=E2=80=9D I=E2=80=99m still cool with that pos= ition, btw. > > As for a name, that can be debated a lot, but I=E2=80=99d like to see so= mething > new, easy to use and unambiguous. If you are looking for a suggestion > for that name, let=E2=80=99s go with WANTS_PIE. Only Makefiles can set it= . > > WANTS_PIE undefined means do the default behavior as defined by the > current MK_PIE setting and perhaps system policy. =E2=80=9CGo with this f= low." > > WANTS_PIE=3Dyes means that if MK_PIE is =E2=80=9Cyes=E2=80=9D, then do PI= E things for > this thing we=E2=80=99re building. If MK_PIE is =E2=80=9Cno=E2=80=9D, tho= ugh PIE is disabled for > everything. > > WANTS_PIE=3Dno means that if MK_PIE is =E2=80=9Cyes=E2=80=9D, then disabl= e doing PIE > things for this component. If MK_PIE is no, it is also disabled. > > This could also be extended to NEEDS_foo, which says =E2=80=9CI need foo = to > build, and if MK_foo is set to no, don=E2=80=99t build me.=E2=80=9D I don= =E2=80=99t think anything > that you are doing falls into this category though. > > WANTS/NEEDS also avoids the historical use of USE in the ports tree > possibly creating confusion. > > If you go with WANTS_PIE, then you wouldn=E2=80=99t need bad.*.pie.mk. > > Comments? I like that idea. I think we need buy off from Kostik. David, what are your thoughts? Thanks, Shawn From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 14:19:06 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C59E5AF1 for ; Fri, 17 Oct 2014 14:19:06 +0000 (UTC) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32265CE7 for ; Fri, 17 Oct 2014 14:19:05 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gm9so782433lab.27 for ; Fri, 17 Oct 2014 07:19:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zLKTejNljA0IeNEfq/CQWr7+mToPRLnZiOkDsVA1Ev8=; b=L2D+t2VlgSEidAUthuwU3lV8pCjrLOCZGNn2SCF1AjuC4HupMxx8fP18rJRyg46nT4 PsWZTWuOBmDzTO7aZlZRPFxZ7VcGHr6/t7h5fdYLI8dVew2KDwVXHtyqpVz7Syew3pF1 5e6tV9BXav++HPLIAG2JF2vyua9lvvDbm8V3uPSm9gZWonM27Qr7kAzsrIchX8UaEJcf XZyy5WfAZ90BkIcDMrdkw0vsgIuSqW1gzlz794ubDLZAdeY8JvmRYLGLlNDr4l2KnYLM EBntiqDc6J707q12KFiCfhKsWl3cDBW+laM3a92jJ2xI8RRJ8qZXlhSUERZza9g3ViS+ G0ag== X-Gm-Message-State: ALoCoQkSl/RqjaMuBng6KPPa5QdVOlk7yvR4Vfh8Vi4/W6bu+qxnacv3FOljkxK1ezGypqdHssDq MIME-Version: 1.0 X-Received: by 10.152.43.97 with SMTP id v1mr9148859lal.3.1413555543450; Fri, 17 Oct 2014 07:19:03 -0700 (PDT) Received: by 10.25.23.85 with HTTP; Fri, 17 Oct 2014 07:19:03 -0700 (PDT) X-Originating-IP: [185.58.16.66] In-Reply-To: References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> Date: Fri, 17 Oct 2014 15:19:03 +0100 Message-ID: Subject: Re: PIE/PIC support on base From: David Carlier To: Shawn Webb , Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: PaX Team , FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:19:06 -0000 Agreed with couple WANT_PIE/MK_PIE. Regards. On Fri, Oct 17, 2014 at 3:10 PM, Shawn Webb wrote: > On Fri, Oct 17, 2014 at 10:05 AM, Warner Losh wrote: > >> [[cc trimmed ]] >> >> >> On Oct 17, 2014, at 7:46 AM, Shawn Webb wrote: >> >> > On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh wrote: >> > >> > On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: >> > >> > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen >> wrote: >> > > >> > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb >> wrote: >> > >>> >> > >>> >> > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen >> wrote: >> > >>>> >> > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier >> > >>>> wrote: >> > >>>>> >> > >>>>> I chose the "atomic" approach, at the moment very few binaries a= re >> > >>>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the >> > >> needed >> > >>>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flags >> only if >> > >>>>> you >> > >>>>> include (which include ...) >> otherwise >> > >>>>> other >> > >>>>> binaries include as usual hence does not apply. >> Look >> > >>>>> reasonable approach ? >> > >>>> >> > >>>> I think I understand what you mean. But I think PIE is commonpla= ce >> > >>>> nowadays and I don't understand what you win by not enabling it f= or >> > >>>> the whole system. Is it a performance concern? Is it to preserv= e >> > >>>> conservative minds from to much change? :) >> > >>> >> > >>> >> > >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean >> Bruno. >> > >>> >> > >>> On i386, there is a performance cost due to not having an extra >> register >> > >>> available for the relocation work that has to happen. PIE doesn't >> carry >> > >> much >> > >>> of a performance penalty on amd64, though it still does carry some >> on >> > >> first >> > >>> resolution of functions (due to the extra relocation step the RTLD >> has to >> > >>> worry about). On amd64, after symbol resolution has taken place, >> there >> > >> is no >> > >>> further performance penalty due to amd64 having an extra register >> to use >> > >> for >> > >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carries >> on ARM, >> > >>> AArch64, and sparc64. >> > >>> >> > >>> Certain folk would prefer to see PIE enabled only in certain >> > >> applications. >> > >>> /bin/ls can't really make much use of PIE. But sshd can. I >> personally >> > >> would >> > >>> like to see all of base's applications compiled as PIEs, but that'= s >> a >> > >> long >> > >>> ways off. It took OpenBSD several years to accomplish that. Having >> > >> certain >> > >>> high-visibility applications (like sshd, inetd, etc) is a great >> start. >> > >>> Providing a framework for application developers to opt their >> application >> > >>> into PIE is another great start. >> > >>> >> > >>> Those are my two cents. >> > >> >> > >> OK. As long as i386 is still an important architecture, it can mak= e >> > >> sense to enable this on a per-binary basis if we don't want to have= a >> > >> discrepancy between archs. Also I buy your argument on /bin/ls but = I >> > >> was challenging to enable for the whole system because I wonder if >> > >> there aren't some unexpected attack surfaces, besides the obvious >> ones >> > >> (servers). >> > >> >> > >> Do you know what took so much time to OpenBSD? >> > > >> > > >> > > In a private conversation with Theo, I realized that my recollection >> of the >> > > time it took OpenBSD to compile all of base as PIEs was wrong. >> Quoting him: >> > > >> > > "It took 5 people approximately 3 months to debug it, activate it, a= nd >> > > start shipping it the next release. That was on amd64, for all >> > > dynamically linked binaries, except one (a gcc bug took some time to >> > > find). The next architectures followed about 1 or 2 per 6-month >> > > release." >> > > >> > > Given that only one person has worked on this in the past (me) and >> now the >> > > task has been delegated to another (David Carlier), I think we're >> doing >> > > okay on our end. There's a lot of moving parts, and neither of us >> fully >> > > understand all of them completely. We're working on it in >> HardenedBSD, in >> > > the hardened/current/pie branch. >> > > >> > > I'm thinking we might try for a WITH_PIE knob (and *not* use USE_PIE= ) >> and >> > > have certain high-profile applications opt-in to PIE until we work >> out all >> > > the details for everything en masse. Baptiste did bring up a good >> point >> > > with INTERNALLIB and I'm unsure of how we should handle that. >> > >> > WITH_PIE or WITHOUT_PIE controls, on a global basis, via the MK_PIE >> > variable, whether or not the user wants to turn on this feature for >> those >> > program that can do PIE. Designating which programs do, or don=E2=80= =99t, >> > use PIE simply must be done with a different variable. I posted a bit >> of a >> > rant about the current state of things that suggested a couple of >> > alternatives as well as giving some history as to why some options >> > aren=E2=80=99t to be used and the history behind some of my reactions.= :) >> > >> > For this reason, I think WITH_PIE, as I understand your proposal, >> > likely isn=E2=80=99t a good fit with other WITH_xxx variables used in = the src >> > tree today. >> > >> > Gotcha. To be honest, I found your email a tad bit confusing. Are you >> suggesting we create an ENABLE_feature framework? Or are you suggesting = we >> have a USE_PIE flag? Or are you suggesting something different entirely >> (and if you are, what?)? >> >> I=E2=80=99m saying we don=E2=80=99t have a good framework at the moment = to do this. We >> have several bad ones that all have their pitfalls. This is one reason I >> had >> the fast reaction to NO_PIE, then a minute later said =E2=80=9Cgo ahead = and use >> it and I=E2=80=99ll fix it.=E2=80=9D I=E2=80=99m still cool with that po= sition, btw. >> >> As for a name, that can be debated a lot, but I=E2=80=99d like to see s= omething >> new, easy to use and unambiguous. If you are looking for a suggestion >> for that name, let=E2=80=99s go with WANTS_PIE. Only Makefiles can set i= t. >> >> WANTS_PIE undefined means do the default behavior as defined by the >> current MK_PIE setting and perhaps system policy. =E2=80=9CGo with this = flow." >> >> WANTS_PIE=3Dyes means that if MK_PIE is =E2=80=9Cyes=E2=80=9D, then do P= IE things for >> this thing we=E2=80=99re building. If MK_PIE is =E2=80=9Cno=E2=80=9D, th= ough PIE is disabled for >> everything. >> >> WANTS_PIE=3Dno means that if MK_PIE is =E2=80=9Cyes=E2=80=9D, then disab= le doing PIE >> things for this component. If MK_PIE is no, it is also disabled. >> >> This could also be extended to NEEDS_foo, which says =E2=80=9CI need foo= to >> build, and if MK_foo is set to no, don=E2=80=99t build me.=E2=80=9D I do= n=E2=80=99t think anything >> that you are doing falls into this category though. >> >> WANTS/NEEDS also avoids the historical use of USE in the ports tree >> possibly creating confusion. >> >> If you go with WANTS_PIE, then you wouldn=E2=80=99t need bad.*.pie.mk. >> >> Comments? > > > I like that idea. I think we need buy off from Kostik. David, what are > your thoughts? > > Thanks, > > Shawn > From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 15:59:16 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7B9B7D9 for ; Fri, 17 Oct 2014 15:59:16 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id A4502A30 for ; Fri, 17 Oct 2014 15:59:16 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 2D7AA5A9F25; Fri, 17 Oct 2014 15:59:10 +0000 (UTC) Date: Fri, 17 Oct 2014 15:59:10 +0000 From: Brooks Davis To: Warner Losh Subject: Re: PIE/PIC support on base Message-ID: <20141017155909.GB22778@spindle.one-eyed-alien.net> References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: PaX Team , FreeBSD Arch , Shawn Webb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:59:17 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 17, 2014 at 08:05:57AM -0600, Warner Losh wrote: > [[cc trimmed ]] >=20 > On Oct 17, 2014, at 7:46 AM, Shawn Webb wrote: >=20 > > On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh wrote: > >=20 > > On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: > >=20 > > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen wro= te: > > > > > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb wro= te: > > >>> > > >>> > > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen w= rote: > > >>>> > > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > > >>>> wrote: > > >>>>> > > >>>>> I chose the "atomic" approach, at the moment very few binaries are > > >>>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the > > >> needed > > >>>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flags on= ly if > > >>>>> you > > >>>>> include (which include ...) otherw= ise > > >>>>> other > > >>>>> binaries include as usual hence does not apply. Look > > >>>>> reasonable approach ? > > >>>> > > >>>> I think I understand what you mean. But I think PIE is commonplace > > >>>> nowadays and I don't understand what you win by not enabling it for > > >>>> the whole system. Is it a performance concern? Is it to preserve > > >>>> conservative minds from to much change? :) > > >>> > > >>> > > >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Br= uno. > > >>> > > >>> On i386, there is a performance cost due to not having an extra reg= ister > > >>> available for the relocation work that has to happen. PIE doesn't c= arry > > >> much > > >>> of a performance penalty on amd64, though it still does carry some = on > > >> first > > >>> resolution of functions (due to the extra relocation step the RTLD = has to > > >>> worry about). On amd64, after symbol resolution has taken place, th= ere > > >> is no > > >>> further performance penalty due to amd64 having an extra register t= o use > > >> for > > >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carries o= n ARM, > > >>> AArch64, and sparc64. > > >>> > > >>> Certain folk would prefer to see PIE enabled only in certain > > >> applications. > > >>> /bin/ls can't really make much use of PIE. But sshd can. I personal= ly > > >> would > > >>> like to see all of base's applications compiled as PIEs, but that's= a > > >> long > > >>> ways off. It took OpenBSD several years to accomplish that. Having > > >> certain > > >>> high-visibility applications (like sshd, inetd, etc) is a great sta= rt. > > >>> Providing a framework for application developers to opt their appli= cation > > >>> into PIE is another great start. > > >>> > > >>> Those are my two cents. > > >> > > >> OK. As long as i386 is still an important architecture, it can make > > >> sense to enable this on a per-binary basis if we don't want to have a > > >> discrepancy between archs. Also I buy your argument on /bin/ls but I > > >> was challenging to enable for the whole system because I wonder if > > >> there aren't some unexpected attack surfaces, besides the obvious on= es > > >> (servers). > > >> > > >> Do you know what took so much time to OpenBSD? > > > > > > > > > In a private conversation with Theo, I realized that my recollection = of the > > > time it took OpenBSD to compile all of base as PIEs was wrong. Quotin= g him: > > > > > > "It took 5 people approximately 3 months to debug it, activate it, and > > > start shipping it the next release. That was on amd64, for all > > > dynamically linked binaries, except one (a gcc bug took some time to > > > find). The next architectures followed about 1 or 2 per 6-month > > > release." > > > > > > Given that only one person has worked on this in the past (me) and no= w the > > > task has been delegated to another (David Carlier), I think we're doi= ng > > > okay on our end. There's a lot of moving parts, and neither of us ful= ly > > > understand all of them completely. We're working on it in HardenedBSD= , in > > > the hardened/current/pie branch. > > > > > > I'm thinking we might try for a WITH_PIE knob (and *not* use USE_PIE)= and > > > have certain high-profile applications opt-in to PIE until we work ou= t all > > > the details for everything en masse. Baptiste did bring up a good poi= nt > > > with INTERNALLIB and I'm unsure of how we should handle that. > >=20 > > WITH_PIE or WITHOUT_PIE controls, on a global basis, via the MK_PIE > > variable, whether or not the user wants to turn on this feature for tho= se > > program that can do PIE. Designating which programs do, or don?t, > > use PIE simply must be done with a different variable. I posted a bit o= f a > > rant about the current state of things that suggested a couple of > > alternatives as well as giving some history as to why some options > > aren?t to be used and the history behind some of my reactions. :) > >=20 > > For this reason, I think WITH_PIE, as I understand your proposal, > > likely isn?t a good fit with other WITH_xxx variables used in the src > > tree today. > >=20 > > Gotcha. To be honest, I found your email a tad bit confusing. Are you s= uggesting we create an ENABLE_feature framework? Or are you suggesting we h= ave a USE_PIE flag? Or are you suggesting something different entirely (and= if you are, what?)? >=20 > I?m saying we don?t have a good framework at the moment to do this. We > have several bad ones that all have their pitfalls. This is one reason I = had > the fast reaction to NO_PIE, then a minute later said ?go ahead and use > it and I?ll fix it.? I?m still cool with that position, btw. >=20 > As for a name, that can be debated a lot, but I?d like to see something > new, easy to use and unambiguous. If you are looking for a suggestion > for that name, let?s go with WANTS_PIE. Only Makefiles can set it. >=20 > WANTS_PIE undefined means do the default behavior as defined by the > current MK_PIE setting and perhaps system policy. ?Go with this flow." >=20 > WANTS_PIE=3Dyes means that if MK_PIE is ?yes?, then do PIE things for > this thing we?re building. If MK_PIE is ?no?, though PIE is disabled for > everything. >=20 > WANTS_PIE=3Dno means that if MK_PIE is ?yes?, then disable doing PIE > things for this component. If MK_PIE is no, it is also disabled. >=20 > This could also be extended to NEEDS_foo, which says ?I need foo to > build, and if MK_foo is set to no, don?t build me.? I don?t think anything > that you are doing falls into this category though. >=20 > WANTS/NEEDS also avoids the historical use of USE in the ports tree > possibly creating confusion.=20 >=20 > If you go with WANTS_PIE, then you wouldn?t need bad.*.pie.mk. >=20 > Comments? I think WANTS/NEEDS would address the cases where we've added USE_ variables in our (SRI/Cambridge) external tree. I agree it's a good idea to keep the names orthogonal with ports. -- Brooks --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRBPM0ACgkQXY6L6fI4GtRiRQCfXsxjo3XtzxgyR5sDYN6bp3WB rKgAoIcBzJ7zQB95gwt6xQd99Lm56C09 =gF2V -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 20:28:35 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E39B2F06; Fri, 17 Oct 2014 20:28:35 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95FFEA0C; Fri, 17 Oct 2014 20:28:35 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9HKSGKP045196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 17 Oct 2014 13:28:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54417BD8.30603@freebsd.org> Date: Sat, 18 Oct 2014 04:28:08 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marko Zec , Marius Strobl Subject: Re: Enabling VIMAGE by default for FreeBSD 11? References: <04e9a883-574f-47e8-ae65-29e6d6568712@email.bluemailapp.com> <20141017113737.GA16736@alchemy.franken.de> <20141017135142.3f5a713c@x23> In-Reply-To: <20141017135142.3f5a713c@x23> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , Adrian Chadd , "freebsd-virtualization@freebsd.org" , FreeBSD Net , freebsd-arch , Kris Moore X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 20:28:36 -0000 On 10/17/14, 7:51 PM, Marko Zec wrote: > On Fri, 17 Oct 2014 13:37:37 +0200 > Marius Strobl wrote: > >> On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote: >>> On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: >>> >>>> It was for a while in 9.2, but we removed it from 10.0 and later >>>> due to stability issues we kept getting reports about. Haven't >>>> tried it since then, dont know if those issues are fixed. >>>> >>> I fixed some of the problems with VIMAGE that I encountered with >>> Bluetooth: >>> >>> https://lists.freebsd.org/pipermail/svn-src-head/2013-July/049582.html >> ... which still lacks a proper implementation that doesn't constitute >> a gross layering violation in generic bus code. > By all means please go ahead and propose a layering-clean alternative, > not as ugly and intrusive as this part which I assume bodes you eyes: > > - return (device_attach(dev)); > + > + CURVNET_SET_QUIET(vnet0); > + error = device_attach(dev); > + CURVNET_RESTORE(); > + return error; > > Marko > I think he means the entire bluetooth implementation, which is done from within netgraph. >>> Hiroo Onoo submitted this patch, which I committed to fix problems >>> with VIMAGE encountered with removable USB Ethernet: >>> >>> https://lists.freebsd.org/pipermail/svn-src-all/2014-February/081025.html >>> >>> Martin Matuska committed this fix for PF: >>> https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html >>> >>> So a lot of the stability problems with VIMAGE which were in PC-BSD >>> 9.2 and FreeBSD 9.x have been slowly been fixed. >> Marius >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >