From owner-freebsd-arch@freebsd.org Sun Oct 29 00:36:02 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24D1CE52640; Sun, 29 Oct 2017 00:36:02 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id EE25822B0; Sun, 29 Oct 2017 00:36:01 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 6CDA0176E; Sun, 29 Oct 2017 00:36:01 +0000 (UTC) Subject: Re: Crypto overhaul To: Poul-Henning Kamp , Benjamin Kaduk Cc: Ben Laurie , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Eric McCorkle Message-ID: Date: Sat, 28 Oct 2017 20:36:01 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <24228.1509196559@critter.freebsd.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 00:36:02 -0000 On 10/28/2017 09:15, Poul-Henning Kamp wrote: > -------- > In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: > >> I would say that the 1.1.x series is less bad, especially on the last count, >> but don't know how much you've looked at the differences in the new branch. > > While "less bad" is certainly a laudable goal for OpenSSL, I hope > FreeBSD has higher ambitions. > I'm curious about your thoughts on LibreSSL as a possible option. From owner-freebsd-arch@freebsd.org Sun Oct 29 02:19:36 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABFAAE56002 for ; Sun, 29 Oct 2017 02:19:36 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 22251668A1 for ; Sun, 29 Oct 2017 02:19:35 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: a398f57b-bc4f-11e7-a938-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id a398f57b-bc4f-11e7-a938-4f970e858fdb; Sun, 29 Oct 2017 02:19:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9T2JRi1002184 for ; Sat, 28 Oct 2017 20:19:27 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509243567.56824.103.camel@freebsd.org> Subject: Allow faster eventhandler dispatching by keeping pointers to handler lists. From: Ian Lepore To: "freebsd-arch@FreeBSD.org" Date: Sat, 28 Oct 2017 20:19:27 -0600 Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 02:19:36 -0000 There has been some talk lately of the kernel eventhandler mechanism being inefficient due to holding a lock while walking a global list doing strcmp() to find the right list of handlers.  I've posted a phabricator review to alleviate that by allowing high-frequency events to pre-define the event list and keep a pointer to it, to avoid the name lookups. https://reviews.freebsd.org/D12821 -- Ian From owner-freebsd-arch@freebsd.org Sun Oct 29 03:00:48 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FA72E56C1E for ; Sun, 29 Oct 2017 03:00:48 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CBCE677A1; Sun, 29 Oct 2017 03:00:48 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: by mail-pg0-f41.google.com with SMTP id y5so8336763pgq.7; Sat, 28 Oct 2017 20:00:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=vaWWAddJv1iK8Wiq4TUAmxc4Ytk4AaxMNoJdp0kss14=; b=QBuqoj2bvdNdlqIDV6hl3IMz1Xg2EBp1iqjZjKiKHML/zUD7M7Fg2XwAUzRX+lw/cT 3nW2y7rJ1URJIO91MkJg50e8B6a5S+puWuNMw6Ktfu1lEZGBwoRcHsPNnBdcgo3Nzz8a 82ZOkx7MKRt52b3jmWIC/8J2bXn1nSoU4mj3QQAsu4oNV6Xe8DtfjI78nlHkmc8wkrWu Mt4gIQyGsIJJf6mayUDRnyJ5kmOi97x5IZgwV1D5USHtwztPlATL09X8Fn2CcXYi0gV1 kQd2QKmnK26NA+zQOEN4uLyod29uQeeAb28Bv3lgdWcDXKMrutyGRkMuNZ/R16QPGHbf FSTw== X-Gm-Message-State: AMCzsaXry7vkrGV9A2i1j6Vc0q7l+dNWYnN0IgYajNoZlXWQBIVocF/k t0q3w/Ugh5jmaLf232nPmj9nKw2G X-Google-Smtp-Source: ABhQp+S5HslC4PmVpcEsVPtiYv0Wm9c/B4lJmUURnyGQT936uX0wJEOFjEerT6u84PzK1meGzl6lsA== X-Received: by 10.99.123.88 with SMTP id k24mr4276308pgn.213.1509244657789; Sat, 28 Oct 2017 19:37:37 -0700 (PDT) Received: from [192.168.2.122] (174-24-242-218.tukw.qwest.net. [174.24.242.218]) by smtp.gmail.com with ESMTPSA id s71sm22249777pfa.147.2017.10.28.19.37.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Oct 2017 19:37:36 -0700 (PDT) Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. To: Ian Lepore , "freebsd-arch@FreeBSD.org" References: <1509243567.56824.103.camel@freebsd.org> From: Matt Joras Message-ID: <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> Date: Sat, 28 Oct 2017 19:37:35 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1509243567.56824.103.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 03:00:48 -0000 On 10/28/2017 19:19, Ian Lepore wrote: > There has been some talk lately of the kernel eventhandler mechanism > being inefficient due to holding a lock while walking a global list > doing strcmp() to find the right list of handlers.  I've posted a > phabricator review to alleviate that by allowing high-frequency events > to pre-define the event list and keep a pointer to it, to avoid the > name lookups. > > https://reviews.freebsd.org/D12821 > > -- Ian > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" Hah, as it happens I just posted a revision with largely the same intention, though I approached the problem a bit differently: https://reviews.freebsd.org/D12814. Matt From owner-freebsd-arch@freebsd.org Sun Oct 29 06:23:43 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF1FAE5AC53 for ; Sun, 29 Oct 2017 06:23:43 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E5EB6D728 for ; Sun, 29 Oct 2017 06:23:42 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by know-smtprelay-5-imp with bizsmtp id TJPf1w00B0HtmFq01JPfyY; Sun, 29 Oct 2017 06:23:39 +0000 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.1 cv=XuEHQgx9 c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=2rVjqWD_AAAA:8 a=mDV3o1hIAAAA:8 a=fjI6oOUNAAAA:8 a=e5mUnYsNAAAA:8 a=NEAV23lmAAAA:8 a=Aziwk6T4AAAA:8 a=Ye9q-bpsAAAA:8 a=Vt2AcnKqAAAA:8 a=uj8X_y5MAAAA:8 a=5x2gbUjwxCsc-tyLeXgA:9 a=QEXdDO2ut3YA:10 a=kZDNUv_x1BAA:10 a=Zb1NnzInM5wA:10 a=mhBgT-Iy8DAA:10 a=7MtbkP0eYeQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 a=_FVE-zBwftR9WsbkzFJk:22 a=CraPrAVN91dFfRf5Enq8:22 a=Vxmtnl_E_bksehYqCbjh:22 a=mtcElmGe8wx6H7Xd9tIj:22 a=v10HlyRyNeVhbzM4Lqgd:22 a=gp7W3T1CZUxA4ewt6LkN:22 Subject: Re: New reboot flag: -c for 'power cycle' References: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> From: Jonathan de Boyne Pollard To: FreeBSD Arch , FreeBSD Hackers Cc: Supervision Message-ID: <28fa2fa1-d086-6fdf-303c-4a527b807542@NTLWorld.COM> Date: Sun, 29 Oct 2017 06:23:39 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 06:23:44 -0000 Warner Losh: > I was completely unaware of SIGWINCH being used like this on Linux. It > didn't pop up in the quick research I did before implementing this. > > But it would have been nice to know this sooner, but I'm OK with later > since it isn't much later. > Some sources of information for you, and for anyone else interested: * The "System event response" section of my system-manager(1). (http://jdebp.eu./Softwares/nosh/guide/system-manager.html or file:///usr/local/share/doc/nosh/system-manager.html if you have the nosh Guide installed) * The SIGNALS section of Miquel van Smoorenburg's init(8). (http://svn.savannah.gnu.org/viewvc/sysvinit/sysvinit/trunk/man/init.8) * The SIGNALS section of Gerrit Pape's runit(8). (http://smarden.org/runit/runit.8.html) * The SIGNALS section of systemd(8). (https://www.freedesktop.org/software/systemd/man/systemd.html) * The doco for signal handling in Joachim Nilsson's finit. (https://github.com/troglobit/finit/blob/master/doc/signals.md) * Felix von Leitner (2004-09). Speeding up the Linux boot process with minit. https://www.fefe.de/minit/minit-linux-kongress2004.pdf. 11th Linux Kongress. p. 14. * https://unix.stackexchange.com/a/191875/5132 * https://unix.stackexchange.com/a/197472/5132 * https://www.mail-archive.com/supervision@list.skarnet.org/msg01344.html From owner-freebsd-arch@freebsd.org Sun Oct 29 07:05:35 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F03FEE5BA8D; Sun, 29 Oct 2017 07:05:35 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B3B106E993; Sun, 29 Oct 2017 07:05:35 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7F819273A4; Sun, 29 Oct 2017 07:05:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9T75QhH028040; Sun, 29 Oct 2017 07:05:26 GMT (envelope-from phk@phk.freebsd.dk) To: Eric McCorkle cc: Benjamin Kaduk , Ben Laurie , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul In-reply-to: From: "Poul-Henning Kamp" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28038.1509260726.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Oct 2017 07:05:26 +0000 Message-ID: <28039.1509260726@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 07:05:36 -0000 -------- In message , Eric Mc= Corkl e writes: >On 10/28/2017 09:15, Poul-Henning Kamp wrote: >> -------- >> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk wri= tes: >> = >>> I would say that the 1.1.x series is less bad, especially on the last = count, >>> but don't know how much you've looked at the differences in the new br= anch. >> = >> While "less bad" is certainly a laudable goal for OpenSSL, I hope >> FreeBSD has higher ambitions. >> = > >I'm curious about your thoughts on LibreSSL as a possible option. It retains the horrible APIs, so the potential improvement is finite. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Sun Oct 29 07:14:06 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A9C3E5BE16 for ; Sun, 29 Oct 2017 07:14:06 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AC6B6EE7D for ; Sun, 29 Oct 2017 07:14:04 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by know-smtprelay-5-imp with bizsmtp id TKE21w0050HtmFq01KE2VZ; Sun, 29 Oct 2017 07:14:02 +0000 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.1 cv=XuEHQgx9 c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=2rVjqWD_AAAA:8 a=6I5d2MoRAAAA:8 a=Tlk_011yz0e4TaU44bsA:9 a=QEXdDO2ut3YA:10 a=_tMouvQisEEA:10 a=Ba0ZfmD9N8QA:10 a=82-kyh_VXv8A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 a=IjZwj45LgO3ly-622nXo:22 Subject: Re: New reboot flag: -c for 'power cycle' References: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> To: FreeBSD Arch , FreeBSD Hackers From: Jonathan de Boyne Pollard Message-ID: <69a5ac4b-9f71-d016-1dbc-4cc2ceb78fb0@NTLWorld.COM> Date: Sun, 29 Oct 2017 07:14:01 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 07:14:06 -0000 Warner Losh: > * There is a new compatibility fastpowercycle/powercycle command, > with all of the same options for cruel system administrators. > > Hmmm, I like this. I'll have to add it to FreeBSD. I should have > thought of it in the first place. > (-: If you want further ideas like this, I've proposed adding a -b flag and boot_bare variable to the kernel and loader for a while, now. Old BSD init can just treat it as identical to -s, but my softwares can definitely make good use of it. * http://jdebp.eu./Softwares/nosh/roadmap.html#Ideas * https://freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project From owner-freebsd-arch@freebsd.org Sun Oct 29 07:26:22 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA837E5C21D for ; Sun, 29 Oct 2017 07:26:22 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E509D6F45F for ; Sun, 29 Oct 2017 07:26:21 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by know-smtprelay-5-imp with bizsmtp id TKSJ1w00L0HtmFq01KSJgQ; Sun, 29 Oct 2017 07:26:19 +0000 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.1 cv=XuEHQgx9 c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=zCF0BwDtR6fGmel4gz4A:9 a=QEXdDO2ut3YA:10 Subject: Re: New reboot flag: -c for 'power cycle' References: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> To: FreeBSD Arch , FreeBSD Hackers From: Jonathan de Boyne Pollard Message-ID: Date: Sun, 29 Oct 2017 07:26:18 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 07:26:22 -0000 Warner Losh: > * system-manager now treats SIGWINCH differently on non-Linux > operating systems, treading it as a request to invoke a new > powercycle service. > > SIGRTMIN+6, unused in the systemd system, is the Linux equivalent. > > * system-manager now treats SIGRTMIN+16 as the underlying actual > powercycle request, which it translates to either RB_POWERCYCLE if > it is present in the C library headers, or RB_AUTOBOOT if it is not. > > * There is now a new system-control powercycle subcommand, which > defaults to sending SIGWINCH/SIGRTMIN+6 or SIGRTMIN+16. > > It looks like all the SIGRT* signals are user defined, and can be used > for any purpose by the application. It could easily be SIGRTMIN+6 as > it is SIGWINCH and we could ditch SIGWINCH on FreeBSD in init as well > (since it's only been in -current for a few days). Would that suffice > to address the compatibility concerns? There's no reason to be > gratuitously different here. > True, but it's not my softwares that you and I have to worry about. I've just double checked, and the very thing that my softwares themselves are being compatible with here has already used SIGRTMIN+16 and SIGRTMIN+6, so I am going to adjust to +17 and +7 . I'll let the systemd people know. Let's see what transpires from that. From owner-freebsd-arch@freebsd.org Sun Oct 29 13:46:35 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4851AE63B4D; Sun, 29 Oct 2017 13:46:35 +0000 (UTC) (envelope-from bf1783@gmail.com) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 058327E4E6; Sun, 29 Oct 2017 13:46:34 +0000 (UTC) (envelope-from bf1783@gmail.com) Received: by mail-ua0-x22b.google.com with SMTP id n22so7792673uaj.13; Sun, 29 Oct 2017 06:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=G4UHpup1LKcJW4HHj7KPsqUTIe18RGjnzQxd9Ph3rXU=; b=SudsWfA8VD6TE1AjNJxb8guApfUhtJ0XiCzE/0Kaj3ci6xsMAVk8V8UeOefyw6eFn4 ZaSWGZThOyGowjD/H8FcpraUHOOFQ6WhbqVj8Y+yP/RJahdNQan+wmQKcKu6UUbrIquv llhG+pLvJf4RVqAWMG1m2SAGk0d3THKaZ3i4sVOQZ9kfczICW06CXGOo28R6BCoV9gLN CKDTtxmVDfKKFteJ0WO1+xQ1hEDbDWUmASPsyn+80DIG9URGoOtkgpf4v2LHsmuPKdO0 YEkL093P2EgzVgQMVIqhsUjnSi8pX1AyHTLK/dq21s7T09LclrE69437WnKONRKr05GJ DPIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=G4UHpup1LKcJW4HHj7KPsqUTIe18RGjnzQxd9Ph3rXU=; b=CQ7wBuILzPdK4XsoJfgmv6waMKkavmN2ih64XenNVMmusrNt5aTnnqttCSWFD+7Iu+ aJvsKsASwkw6xFR2/gUsGWmnAMFiNPE2bXXhqdhAFSVEn1JKiK3rR2ev+giVaIoY4h51 VyLd7W2KbZtGBrP/cz2lVVjDVau4FxVxSuyKQHPPFeoN8G2NtKhcL/GULEK4ba2OtBve jjrQfVgTayVwAPiMr4suR/jVk2C+pKuXpm7JdgjBDg0gQ81k/f2xuUk2UOWUpVKOnO9f Zi9BHDg6LU/+mCLcGXOcnZ2k/RhAzsijsLRAIpiPflTDo3Epjzok2CDwcE0g5/nSw8Ta md8g== X-Gm-Message-State: AMCzsaX6GkW+xpxY8Vv1Aw9Rn4Y253qTDDvQko57naasmKJnU8smQtbn YsK/gKfFDB5pbirDCA0hZMKel6nDnkkfxYRASxU= X-Google-Smtp-Source: ABhQp+SqMUXHwYgKpGF6enWQxc3auR2/uOGU+VmWxHOuqNUTDYYP3+nUugIr2yAYeD2Lp8l+pjKzyWTqKdxstSk2yoc= X-Received: by 10.176.83.206 with SMTP id l14mr5789821uaa.167.1509284793938; Sun, 29 Oct 2017 06:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.143.142 with HTTP; Sun, 29 Oct 2017 06:46:33 -0700 (PDT) Reply-To: bf1783@gmail.com In-Reply-To: <28039.1509260726@critter.freebsd.dk> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> From: bf Date: Sun, 29 Oct 2017 13:46:33 +0000 Message-ID: Subject: Re: Crypto overhaul To: Poul-Henning Kamp Cc: Eric McCorkle , Benjamin Kaduk , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 13:46:35 -0000 On 10/29/17, Poul-Henning Kamp wrote: > -------- > In message , Eric > McCorkl > e writes: >>On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>> -------- >>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>> writes: >>> >>>> I would say that the 1.1.x series is less bad, especially on the last >>>> count, >>>> but don't know how much you've looked at the differences in the new >>>> branch. >>> >>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>> FreeBSD has higher ambitions. >>> >> >>I'm curious about your thoughts on LibreSSL as a possible option. > > It retains the horrible APIs, so the potential improvement is finite. > OpenBSD started the task of making OpenSSL easier to use by adding things like libtls (see https://man.openbsd.org/tls_init ) on top of their backwards-compatible libssl. There are similar efforts in other libraries like NaCl and its forks, such as libsodium ( cf. https://nacl.cr.yp.to/features.html and https://www.gitbook.com/book/jedisct1/libsodium/details ). Are these the kind of changes you are suggesting? Regards, b.f. From owner-freebsd-arch@freebsd.org Sun Oct 29 15:18:00 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2CE3AE40E8F; Sun, 29 Oct 2017 15:18:00 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 00BC6810D6; Sun, 29 Oct 2017 15:17:59 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 4A18018C4; Sun, 29 Oct 2017 15:17:59 +0000 (UTC) Subject: Re: Crypto overhaul To: bf1783@gmail.com, Poul-Henning Kamp Cc: Benjamin Kaduk , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> From: Eric McCorkle Message-ID: <61210249-105c-974c-1dae-1837e5969054@metricspace.net> Date: Sun, 29 Oct 2017 11:17:58 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 15:18:00 -0000 On 10/29/2017 09:46, bf wrote: > On 10/29/17, Poul-Henning Kamp wrote: >> -------- >> In message , Eric >> McCorkl >> e writes: >>> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>>> -------- >>>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>>> writes: >>>> >>>>> I would say that the 1.1.x series is less bad, especially on the last >>>>> count, >>>>> but don't know how much you've looked at the differences in the new >>>>> branch. >>>> >>>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>>> FreeBSD has higher ambitions. >>>> >>> >>> I'm curious about your thoughts on LibreSSL as a possible option. >> >> It retains the horrible APIs, so the potential improvement is finite. >> > > OpenBSD started the task of making OpenSSL easier to use by adding > things like libtls > > (see https://man.openbsd.org/tls_init ) > > on top of their backwards-compatible libssl. There are similar > efforts in other libraries like NaCl and its forks, such as libsodium > ( cf. https://nacl.cr.yp.to/features.html and > https://www.gitbook.com/book/jedisct1/libsodium/details ). Are these > the kind of changes you are suggesting? I know the LibreSSL roadmap includes more plans to improve the API design to make it more usable. Overall, I think LibreSSL is the best option, though there needs to be some investigation into how easily it can be used for kernel and boot-loader purposes. Things like libsodium are too narrow in their focus, and BearSSL is too new. Plus the fact that LibreSSL originates from one of the BSDs and has its backing is a significant advantage, I think. From owner-freebsd-arch@freebsd.org Sun Oct 29 16:12:45 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AA69E44C2E for ; Sun, 29 Oct 2017 16:12:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 DC83383492 for ; Sun, 29 Oct 2017 16:12:44 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: fac3ad4c-bcc3-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id fac3ad4c-bcc3-11e7-a893-25625093991c; Sun, 29 Oct 2017 16:12:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9TGCWwU001392; Sun, 29 Oct 2017 10:12:32 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509293552.21609.5.camel@freebsd.org> Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. From: Ian Lepore To: Matt Joras , "freebsd-arch@FreeBSD.org" Date: Sun, 29 Oct 2017 10:12:32 -0600 In-Reply-To: <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 16:12:45 -0000 On Sat, 2017-10-28 at 19:37 -0700, Matt Joras wrote: > On 10/28/2017 19:19, Ian Lepore wrote: > > > > There has been some talk lately of the kernel eventhandler > > mechanism > > being inefficient due to holding a lock while walking a global list > > doing strcmp() to find the right list of handlers.  I've posted a > > phabricator review to alleviate that by allowing high-frequency > > events > > to pre-define the event list and keep a pointer to it, to avoid the > > name lookups. > > > > https://reviews.freebsd.org/D12821 > > > > -- Ian > >  > Hah, as it happens I just posted a revision with largely the same > intention, though I approached the problem a bit differently: > https://reviews.freebsd.org/D12814. > > Matt Actually, it looks like we've done nearly identical work, modulo some minor naming differences (that I'm completely agnostic about), and you have the EHL_NONEMPTY flag that didn't occur to me until after I created the phab review last night. The other big difference is that mine still links the fast/static lists into the global list-of-lists, to preserve what I call "late loose binding" where an event handler can register for events before the event provider is present (picture a module that monitors events which gets loaded before a module that produces those events). It ocurred to me this morning that an optimization for mine would be to place any list created by eventhandler_create_list() at the end of the global list, on the theory that it will mostly be accessed directly via pointer and the items at the head of the global list should be the ones more likely to be searched by name. -- Ian From owner-freebsd-arch@freebsd.org Sun Oct 29 16:24:15 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E446E4600B for ; Sun, 29 Oct 2017 16:24:15 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 39599839EA for ; Sun, 29 Oct 2017 16:24:14 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 992f7e04-bcc5-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 992f7e04-bcc5-11e7-a893-25625093991c; Sun, 29 Oct 2017 16:24:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9TGO7km001408; Sun, 29 Oct 2017 10:24:07 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509294247.21609.12.camel@freebsd.org> Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. From: Ian Lepore To: Matt Joras , "freebsd-arch@FreeBSD.org" Date: Sun, 29 Oct 2017 10:24:07 -0600 In-Reply-To: <1509293552.21609.5.camel@freebsd.org> References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 16:24:15 -0000 On Sun, 2017-10-29 at 10:12 -0600, Ian Lepore wrote: > On Sat, 2017-10-28 at 19:37 -0700, Matt Joras wrote: > > > > On 10/28/2017 19:19, Ian Lepore wrote: > > > > > > > > > There has been some talk lately of the kernel eventhandler > > > mechanism > > > being inefficient due to holding a lock while walking a global list > > > doing strcmp() to find the right list of handlers.  I've posted a > > > phabricator review to alleviate that by allowing high-frequency > > > events > > > to pre-define the event list and keep a pointer to it, to avoid the > > > name lookups. > > > > > > https://reviews.freebsd.org/D12821 > > > > > > -- Ian > > >   > > Hah, as it happens I just posted a revision with largely the same > > intention, though I approached the problem a bit differently: > > https://reviews.freebsd.org/D12814. > > > > Matt > > Actually, it looks like we've done nearly identical work, modulo some > minor naming differences (that I'm completely agnostic about), and you > have the EHL_NONEMPTY flag that didn't occur to me until after I > created the phab review last night. > > The other big difference is that mine still links the fast/static lists > into the global list-of-lists, to preserve what I call "late loose > binding" where an event handler can register for events before the > event provider is present (picture a module that monitors events which > gets loaded before a module that produces those events). > > It ocurred to me this morning that an optimization for mine would be to > place any list created by eventhandler_create_list() at the end of the > global list, on the theory that it will mostly be accessed directly via > pointer and the items at the head of the global list should be the ones > more likely to be searched by name. > > -- Ian Oops, I apparently overlooked _eventhandler_insert_static() in your changes.  I think if that were changed to first check whether the new handler list already exists on the global list, our changes really would be essentially identical. -- Ian From owner-freebsd-arch@freebsd.org Sun Oct 29 16:32:55 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE0C3E46241; Sun, 29 Oct 2017 16:32:55 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0104.outbound.protection.outlook.com [104.47.36.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A65383D50; Sun, 29 Oct 2017 16:32:54 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CzDh1clqxHoUZ9hYUWmhxj3MAg1XOBuapGYdsOQC0po=; b=D7DcmpAN+MNU1spcqjpRQSyWAmfO3/QMfmwcGLMrwkaU6Qlly7gclY4dP3A2sH+5mId7x6JNgaEO+nsVY3tYi1wyCnWbb/XSmfL0Ge+xxsFFioDBSz5Nx9zbrEkQaMvQw77+q5cZgioI7VzkKA0dSZjDqjVdcbHZrOGo0UJciWc= Received: from DM5PR05CA0053.namprd05.prod.outlook.com (10.174.188.170) by MWHPR05MB3613.namprd05.prod.outlook.com (10.174.251.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Sun, 29 Oct 2017 16:32:52 +0000 Received: from DM3NAM05FT038.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::200) by DM5PR05CA0053.outlook.office365.com (2603:10b6:4:39::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Sun, 29 Oct 2017 16:32:52 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT038.mail.protection.outlook.com (10.152.98.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.197.9 via Frontend Transport; Sun, 29 Oct 2017 16:32:51 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 29 Oct 2017 09:32:44 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9TGWh4b021885; Sun, 29 Oct 2017 09:32:43 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 89C53385567; Sun, 29 Oct 2017 09:32:43 -0700 (PDT) To: Eric McCorkle CC: , Poul-Henning Kamp , "freebsd-security@freebsd.org security" , Benjamin Kaduk , Ben Laurie , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" , Subject: Re: Crypto overhaul In-Reply-To: <61210249-105c-974c-1dae-1837e5969054@metricspace.net> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> <61210249-105c-974c-1dae-1837e5969054@metricspace.net> Comments: In-reply-to: Eric McCorkle message dated "Sun, 29 Oct 2017 11:17:58 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95043.1509294763.1@kaos.jnpr.net> Date: Sun, 29 Oct 2017 09:32:43 -0700 Message-ID: <95044.1509294763@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(2980300002)(199003)(24454002)(189002)(69596002)(39060400002)(107886003)(47776003)(2950100002)(305945005)(4326008)(221733001)(6916009)(356003)(6266002)(6246003)(50466002)(9686003)(68736007)(55016002)(7696004)(2906002)(5660300001)(77096006)(7116003)(229853002)(53936002)(97756001)(8676002)(54906003)(8936002)(316002)(46406003)(7126002)(76176999)(23726003)(16586007)(2810700001)(50986999)(105596002)(81156014)(81166006)(53416004)(97876018)(189998001)(106466001)(76506005)(50226002)(478600001)(117636001)(97736004)(3480700004)(86362001)(93886005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3613; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT038; 1:BmGzebx+tizseAkHeIUGxoAM0qcDGcBNsP0dVSHjW5KkdAQKkM2nquWsDn0NXv1tg85I7aG/nKbYrHr55A+Ollsk/Fjxup/v4xxCbPcAQXBPfa7wWWEebH4JoNdVxpcU X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b3a3bb25-7021-4aaa-e928-08d51eeab339 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:MWHPR05MB3613; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 3:bLgK3bY0Shy1Q/Hv2FK1t9xbCh/b+ttzpHj+NhFT7Yn02y8ojIngZ13LXCGLvyGOXwj72YwlTE1PvYYj4HX1gO/noz2U87ApukbhsC+0mzh0HDTZWsxPyjGyN4udnddLA0B89avgdGYLQoBTybM+FwMawPYpBkWekjTTPBAbTH42O9LADPyomOe9YXosCKvzd3YeL/HSMUBPLcqrCrM7FAslbUopLfu8te+FTFoBoDrF5BZtxZmW19Snc8yRBls2VI97wM4ZyAbsp4XXL+HPjCBH2hfFl4EWLNfSaf+jZGVSiLl+wOhwTl6KlMxCzVgzW/6eeQ/gNRSyCugEXVVoSxeOxxlvJ6RPPilAOXQ4QD8=; 25:2R5Pb5Jo9W3vsog9iH7gbfWorcUPPbHMjtUsFLtQai6mo9zr7HW5UJ5otTTxTt55HDLwHiDaQA2D3OxHCBMi7hqELIg2/yTGepAI/ra/8BUVYwfc3iZm2maKz8dWMtqGFKhLX/omD69t2J6r+a7nfcnjfT0RpUI69wo+JsUxy/rifdFeqJYa/HUbwf4eyzxFlXhPJzUQsgJUL394iTZ6IM6gF2Hg3ZDWxRqAiwKudHE6djRswtMgC149XApow5Rj60724BhRDdcL37kvCohkFezsKDpTvls8Iv9XsdoHyYZfhv2Cl18WIWJEF2PuMPC7hZHEKnnN2oKNX25gH7Qxyw== X-MS-TrafficTypeDiagnostic: MWHPR05MB3613: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 31:wm2gF+if/HESKjQCwHUx2Je7xDBuMh0CGBmoqQ2oEirHDi1c+48oAdN2tShfdNLQzCrNofqi7e9WLZ9pEsTjcntkYxJYb1z3X3iSuBGeVI68wHZmCFQqFrnbk9JXjGi+MKhz0uYfnZQ/pQLKxhxNL4Qx0mKRUrQVNWyGO73QuwtgP88HsomsNspN++rPSIsJ7U296M7FXKEeGnyGfq7JxPxU2UNAay/62AUGm4xmrmg=; 20:++bdJFmfX7xZp7hW1j2a/Quntk6FENa0En+4r/f65xkl5P2YYYyQgbRG1vrb1e/B9w6wpSV0PLd7ZcIfuJVbTdPLMtF96ED4Ccyke3hOrUi9F9OlD/xYiTmNyDiAfW3hCahrC1mXIo+fb+I1OihycTyr80xo+Ey3FytH+ikLCBOiEAVN+Nhiq29LOfAz2BnM5bNSXFi7aQMugZEMQjx4iOIuMiqjc81SGWDv75AWMuon4MSaTOIk13wTmd+xC08Whf/f9rL61J0Qvt0ml//jj4lBzAodn8HfNnCQheFzMDCXBegQWmosFuhB477iiQ9Q+OIiCUr1IurfqN0V4vNOnfAbYyI+Wqe5DSWdLxSmeV09HBiktMzJAjMjJxrUmZfSgeaSSpG941x8ym4QlcK5pDt1/UN8GAWVPqAPgc/fmpLe29d7KJmnqteVh/sVmqyGZjDTSBU0eOeKki9JJ3xUev/6BMEu0m3ECJL2gRwywR5lh9fm/UpLu3TmPA2og8i9 X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93003095)(3231020)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3613; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3613; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 4:uMOiNQsnJluh2Re5B6oAxIZRBuHYj6qENT0fgc1zMLz10rGIOj007CDYXwum8HIj5zA+cytVGDoaTwvjpubDK6hNUlYUMqdrSCUYANBdb3sJOaLOB0xTm7nk4UHTuo5mxyWBOEv14lFL+1CFPtSdnKP5g39pql7x+DFzFdy1CVz1n+MoyOXuU+P6GiUTkYNUmZvqb7CH+zRzcEikExV+x9tRYA3xbjGtNz/IMsUqhGh6oklqRsRf5AzaTFp9dBRGDlnVUiF6vywLpuCd93U/wQ== X-Forefront-PRVS: 0475418F50 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3613; 23:yCpu+/LqPxjKLASkkkfQyloL41PBjBlKaEJjRrpMI?= =?us-ascii?Q?saCXbMo5Ypd1RpmkqhPTT0pPiqryj2J3JKqVUSDj3rZJKeSe4sh/O9BkUTez?= =?us-ascii?Q?Wju196Zf8fv4O5pUR6xt3yAEJZbnIL26eyqPD7a8P+puYH6zypprtIZSxutn?= =?us-ascii?Q?73g7z+xSGi999JIJUxordVQ3SI73jTvkcj5gCceSc79g9/6N4n+pFzZlAsjv?= =?us-ascii?Q?pViIPXLoc7gPDk3GicShVDAI9lpDiIyCvn/ReaHy5UXAdJ7YZ4Py1tMfzeh1?= =?us-ascii?Q?loOCIny69lsCQX7v8Fbcaa0L9mF1T0j3d0h2Ihtq6TkBBSTbxcpfI0pfb7Gz?= =?us-ascii?Q?a6Z446KyWMwRvhjPfsNZesYZCxCvuDOwzXQEB2JBS7/lbzgFMMYtEdfkIiHT?= =?us-ascii?Q?W3yc4r+FyywR53lhhGR66kqB9NSmYxsf+uXpRMPZ3Yj4ciopZnL7NJxSl0n2?= =?us-ascii?Q?MDJokJ6MNsnnftNPqv8jmFeL7+DvQn56lE/mcCI6xWxjFs2Gk0ggdLBbFKOT?= =?us-ascii?Q?0PJrr+0BKI4CqqOrXSAgPR/BvNEETp0DZVcezjYc3ag+rSN25RTFmywqkMzF?= =?us-ascii?Q?vce1pobcc2DA/cMWH57+CM/zMbHpOlhN7bqkbHxQcKfqafBcalJsVUYwZ9Xa?= =?us-ascii?Q?xfm6NVusgybrYjm6uF5tb0f+eig7d+N1ic01L9rWtCOl3YB6s+zqYoTqXIY5?= =?us-ascii?Q?3hr6KNVibdrKkCpZT3lz8OT60Ky+q3nml+R39mxbucTnA2ISkPnOeNtwB4kj?= =?us-ascii?Q?sOpXPnWb44LpVY/ml/MoUV5b1nKbvHNCOZtJPLDNoYWxUM6Yk1UkRMM8sEVJ?= =?us-ascii?Q?tIj1k+0aOenxW9UpUdsmsr5F77NgQXfC7R0uBd6gdLyKMSLu/YG54Fv4dYtE?= =?us-ascii?Q?/S/rEK+HG4OxUIMoa9MefL/6PMA4Vf8BUnkRBIBnsyn4NrzRRBt/0itp0tiX?= =?us-ascii?Q?zr/HXV+RMVbdHe2lo5mLkJZStIGKqY+5WerD7WbVcYIBugWCECvrNmmASLgE?= =?us-ascii?Q?kSXkz/GNov5TngDKO3jnWMcjRQL8H8W3Ypa7Rv5UjslFVrIR/7veR+7C2CUU?= =?us-ascii?Q?Wsjg7FNeJO+x4fu+Ba5je5YfEubeOMsYa8LzTyFMIswabIJMbAR17WP3lPBP?= =?us-ascii?Q?k9PzKW9Ltwf3Z8X7QfNkduJe2dfXhObsT1qV09b/8BVEEZ/TFVzZzCrH8Y5o?= =?us-ascii?Q?kNmQaBtTdz6KYJXraT5qfNmcyQyUvTrHEzcxMn4G8WbGGuH0D/wWGInSc72Z?= =?us-ascii?Q?jFe/G0NFY9UvHGBJ3YGS39S/HdibSBjOq5oyuQFsd750V7D/urA2vUPVnlfY?= =?us-ascii?Q?TE+ob63WvmaCbooBFea2pZ28wBq4A8yYm3N9lNUKgx7?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 6:eEHU3pjfCt7i6ArWSmL8OXvD24uOJ/SNM+ujZmFjuQMrsvs8bTzExu94Kwvu6N9PKKqFI3p2Z27JYYILVdSXPuo5N0oUzjT600w8P4+jU7g1N9hzk9bgeh+Gc9MaJWrfeCMcEFOUv0wCqWHdjAKIskmB53S+OouECtSB4NX67ayIHeWIF1aszffB71HS5RAn/TUbwEbeMguSNyfz/jA7T9sY17NCS4djW+4BbmKCn7G9tAW3FOV5vC9XTy10gFZMepUwFifNxuYTI7k1Vr0/azYT2XKjp2GemOk4eRQFMTNxHE7fyXJExw7Gpf12rbXdlhPt/f10kDCmaGX8va/8dVW1ZLMWyq0eqo/neDwGZY4=; 5:dLz/hTJ/rTR4iF3Fnsbdw1SkYWIGaxp4sotHPbniD7pFTig9iMqbdk79DEPxtd5E69Y8J98yB/AuTXfy7/IgklRdtKvX853M+YPgfATzo04HQu6XGSTqN6CQM++ZfxfSOjuP9DpxE1wPnkeeSqE/C8qXkD1ycBuZOtFjaDqqMPA=; 24:gcjPSsI4fkdMikhRUzntLi3d5mmfyvfM2esZafz0KaQGSU8WYdi+nd0QSnbgXZfVQZlH0XqpgfTxbV2/zBZLRZ8BzCYd9AhfMj7NwRr/vz0=; 7:oaLcwtnT9773JR4cUa39WOVAC6CVfZJONndCmL9Sz6NTeYQToJrAf7FJb6hX7b/hbSzl+PfzwrNMxieCiEUVysByLL9HWZObHiFrJbnRl5YcWH55q4DCVR4ZSBfa+LQlNR+uNxtNWdR3AutImcANAXKs32IxJrHL6/1AtrmVUA4XQGfnYGXdzlbwjv87eIL6joXpbcLtDCN94mlU/5sVlryFEw/d8as3LC2p1qr1Desxw9MG3K/P66hDWypbCLDm SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2017 16:32:51.5103 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b3a3bb25-7021-4aaa-e928-08d51eeab339 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3613 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 16:32:55 -0000 Eric McCorkle wrote: > Overall, I think LibreSSL is the best option, though there needs to be > some investigation into how easily it can be used for kernel and > boot-loader purposes. Things like libsodium are too narrow in their > focus, and BearSSL is too new. Our userland veriexec binary uses a libverify which is mostly just OpenSSL (originally structured that way for export reasons ;-) is 3.6M - at least 90% of that is just OpenSSL. I tried paring that library down to just the bits needed for loader. But had to give up at 3M. Which was when I encounterd BearSSL. Out of the box, it could verify our ECDSA cert chains as well as various RSA ones which was a pleasant surprise. libbearssl is < 1M and my loader is 347K with verifcation vs 237K without, so the entire verifcation implementation is only 110K --sjg From owner-freebsd-arch@freebsd.org Sun Oct 29 16:47:21 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6648DE46818 for ; Sun, 29 Oct 2017 16:47:21 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com [209.85.192.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4165C843A1; Sun, 29 Oct 2017 16:47:20 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: by mail-pf0-f172.google.com with SMTP id b85so8884903pfj.13; Sun, 29 Oct 2017 09:47:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6g6mrjvA4g3hZMjRXZEkI04GIIBg4OOR2dqlkQiTiR0=; b=ICPV6vKdBMljL/CjG0eiqChK4Bg7RI8UgCsp0eMss5DAStEEqwYq7CvHeWwTj0DPzw KRrhVygQWUppSyEE6Tp26vHzMLaPdKi+btBIja4dE8BzHkqUmUjuEhmoyjm1A/NY+ZJq 6/JviKZEVW10upcREk5FaMDbjQRgrIx99a4pZOzbZVd2LSR2DOzEPcJgg38q0u+97lj5 2n4YdT0toCLCkKw3rU+lAc526aqF5s+uiECLZlHIy2j4mF/jtEykts+z1afB3BKA1CVk ht2J6ZjVEiYG5q+SNxQuVto02DcB6hrkJ2W7zr9AlFCrLbRQqPLUX6QjsJRWNgoswaQ4 PiQA== X-Gm-Message-State: AMCzsaXjssjhSVZCzmxalAXHJDHCSKUbQGFm+vQU4Cugr7KHP2b6uoNG BOauBoyLMAJK1pbauW8SX5zA6eFe X-Google-Smtp-Source: ABhQp+TqUWzbQ26E0PN0CRUcnHj5UIIKNykZwC/GOyxRY48i8pxZeHBh/M85LhHbvjsgNTj3o/DfGQ== X-Received: by 10.99.53.11 with SMTP id c11mr5410576pga.162.1509295130472; Sun, 29 Oct 2017 09:38:50 -0700 (PDT) Received: from [192.168.2.123] (174-24-242-218.tukw.qwest.net. [174.24.242.218]) by smtp.gmail.com with ESMTPSA id c1sm23265362pfa.12.2017.10.29.09.38.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Oct 2017 09:38:49 -0700 (PDT) Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. To: Ian Lepore , "freebsd-arch@FreeBSD.org" References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> <1509294247.21609.12.camel@freebsd.org> From: Matt Joras Message-ID: <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> Date: Sun, 29 Oct 2017 09:38:48 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1509294247.21609.12.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 16:47:21 -0000 On 10/29/2017 09:24, Ian Lepore wrote: > On Sun, 2017-10-29 at 10:12 -0600, Ian Lepore wrote: >> Actually, it looks like we've done nearly identical work, modulo some >> minor naming differences (that I'm completely agnostic about), and you >> have the EHL_NONEMPTY flag that didn't occur to me until after I >> created the phab review last night. >> >> The other big difference is that mine still links the fast/static lists >> into the global list-of-lists, to preserve what I call "late loose >> binding" where an event handler can register for events before the >> event provider is present (picture a module that monitors events which >> gets loaded before a module that produces those events). >> >> It ocurred to me this morning that an optimization for mine would be to >> place any list created by eventhandler_create_list() at the end of the >> global list, on the theory that it will mostly be accessed directly via >> pointer and the items at the head of the global list should be the ones >> more likely to be searched by name. >> >> -- Ian > Oops, I apparently overlooked _eventhandler_insert_static() in your > changes.  I think if that were changed to first check whether the new > handler list already exists on the global list, our changes really > would be essentially identical. > > -- Ian Indeed. The other difference I noted is that my version statically-allocates the actual list structs, and relies on static initialization, whereas yours uses malloc and initializes them explicitly. How would you like to proceed? Matt From owner-freebsd-arch@freebsd.org Sun Oct 29 17:03:52 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A45D8E471CC for ; Sun, 29 Oct 2017 17:03:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 E06DE84EBC for ; Sun, 29 Oct 2017 17:03:51 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 21d9b00a-bccb-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 21d9b00a-bccb-11e7-a893-25625093991c; Sun, 29 Oct 2017 17:03:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9TH3iiK001491; Sun, 29 Oct 2017 11:03:44 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509296624.21609.24.camel@freebsd.org> Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. From: Ian Lepore To: Matt Joras , "freebsd-arch@FreeBSD.org" Date: Sun, 29 Oct 2017 11:03:44 -0600 In-Reply-To: <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> <1509294247.21609.12.camel@freebsd.org> <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 17:03:52 -0000 On Sun, 2017-10-29 at 09:38 -0700, Matt Joras wrote: > On 10/29/2017 09:24, Ian Lepore wrote: > > > > On Sun, 2017-10-29 at 10:12 -0600, Ian Lepore wrote: > > > > > > Actually, it looks like we've done nearly identical work, modulo some > > > minor naming differences (that I'm completely agnostic about), and you > > > have the EHL_NONEMPTY flag that didn't occur to me until after I > > > created the phab review last night. > > > > > > The other big difference is that mine still links the fast/static lists > > > into the global list-of-lists, to preserve what I call "late loose > > > binding" where an event handler can register for events before the > > > event provider is present (picture a module that monitors events which > > > gets loaded before a module that produces those events). > > > > > > It ocurred to me this morning that an optimization for mine would be to > > > place any list created by eventhandler_create_list() at the end of the > > > global list, on the theory that it will mostly be accessed directly via > > > pointer and the items at the head of the global list should be the ones > > > more likely to be searched by name. > > > > > > -- Ian > > Oops, I apparently overlooked _eventhandler_insert_static() in your > > changes.  I think if that were changed to first check whether the new > > handler list already exists on the global list, our changes really > > would be essentially identical. > > > > -- Ian > Indeed. The other difference I noted is that my version > statically-allocates the actual list structs, and relies on static > initialization, whereas yours uses malloc and initializes them explicitly. > > How would you like to proceed? > > Matt > Oh.  Right.  Hmmm, I think malloc() is required to support the case where a handler registers before the static list init is invoked, and I do think that's a useful feature to preserve.  That means the lists aren't really static, though, which then makes STATIC a bit out of place in the new function/macro names. >From my version of the changes, I really liked then names EVENTHANDLER_DEFINE_LIST() and EVENTHANDLER_DECLARE_LIST() because they so exactly say what they do.  On the other hand, I hate EVENTHANDLER_INVOKE_LIST(), I just couldn't think of anything better.  I considered FAST where LIST appears, playing off the existing 'slow' comments, but it seems to somehow imply the handlers themselves are different or faster, which is all wrong. -- Ian From owner-freebsd-arch@freebsd.org Sun Oct 29 17:15:15 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0CCBE475D7; Sun, 29 Oct 2017 17:15:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9465D3D4; Sun, 29 Oct 2017 17:15:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qk0-x243.google.com with SMTP id x82so13545215qkb.12; Sun, 29 Oct 2017 10:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KbBIk4wF/ij5htrJk8qDFgL2DO374EEvnIRSz+M4u14=; b=bjSZ1Y5IhkazDMzTcfW2GEKDpV9cpLSj73QkxfldZqtTNn6kyVO6B8JVtaBRWM+N9U 7Wq02fQsjosLL7Jv9fX2ONrakCnz/1IB2nJOKyLjgIbn/zovHvMSs5yVqKrla/IJ7SL4 lxQqIL29Ay+Xn9EI/ERl0Ram6ZpPByr6Jz2UBeGKrXqdyZsavjsuynW1nQp6uFolIU7Q QEHZydTVU9K24bZMmE5NyUMn5Sg3y072y3LXX5HP5qQ5jRsuHaKf6PrtySfL6dHexY/d KJJJQTfoRot9mLAvqu3vZoFxFQiO99Y2OmNrw8U1zujWhZGGOL4uA/0O+tONJ+sbr1r4 u84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KbBIk4wF/ij5htrJk8qDFgL2DO374EEvnIRSz+M4u14=; b=ktaoKyARD/rwJdWMtd8IdWIgveryEkf/iXs7jAkYCVv7Rf8mR0uf3nr8iJEuw263dO 8DMnXRxFz0UfbyVYrt0EjTR+aF5x1cTJJ3fcbEHNQQSw3RspPwS9YZwsQLdg5Rlcl7Dn GzQLOW/rNBw+dFiygTyffCJ7/UlzsSu22hzNxPS0QCEOuQcef6Wcmgg/BfI8rXe4jDOa uY1RHWKLJ7Y/Ua1cKlzcFf3RRyC3tqPZleRqeAQxVnEAO2ah/zG9eMWhKc4uXlN1OXCR aYmIxd257HCtG5Vdb2eOTIjyapQPK5xB76h998k3g0KHKT+gs63YhqofRHEwXkyA1i1H U21A== X-Gm-Message-State: AMCzsaWaSG83MkoKTbep5LstQ16Y/xfjDSUJtVfCflHTqqFhsuPS/hWI dZw8fXhePgrDK8uknLJQqJemDcB1iCz1qNSbJUs= X-Google-Smtp-Source: ABhQp+SHLAgMCXgjFKe2WMS89jNcGetcVG7fne3MoLNveq0lAcg97BCgjl7cLYIPXQbZ377mzsJi5JCKQmyA7tvKe/k= X-Received: by 10.55.197.20 with SMTP id p20mr9680636qki.229.1509297314773; Sun, 29 Oct 2017 10:15:14 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Sun, 29 Oct 2017 10:15:14 -0700 (PDT) In-Reply-To: <61210249-105c-974c-1dae-1837e5969054@metricspace.net> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> <61210249-105c-974c-1dae-1837e5969054@metricspace.net> From: Ben Laurie Date: Sun, 29 Oct 2017 17:15:14 +0000 X-Google-Sender-Auth: YL3p4S4Fawfv-h3A9jWw9YR424Y Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: bf1783@gmail.com, Poul-Henning Kamp , Benjamin Kaduk , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 17:15:16 -0000 On 29 October 2017 at 15:17, Eric McCorkle wrote: > On 10/29/2017 09:46, bf wrote: >> On 10/29/17, Poul-Henning Kamp wrote: >>> -------- >>> In message , Eric >>> McCorkl >>> e writes: >>>> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>>>> -------- >>>>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>>>> writes: >>>>> >>>>>> I would say that the 1.1.x series is less bad, especially on the last >>>>>> count, >>>>>> but don't know how much you've looked at the differences in the new >>>>>> branch. >>>>> >>>>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>>>> FreeBSD has higher ambitions. >>>>> >>>> >>>> I'm curious about your thoughts on LibreSSL as a possible option. >>> >>> It retains the horrible APIs, so the potential improvement is finite. >>> >> >> OpenBSD started the task of making OpenSSL easier to use by adding >> things like libtls >> >> (see https://man.openbsd.org/tls_init ) >> >> on top of their backwards-compatible libssl. There are similar >> efforts in other libraries like NaCl and its forks, such as libsodium >> ( cf. https://nacl.cr.yp.to/features.html and >> https://www.gitbook.com/book/jedisct1/libsodium/details ). Are these >> the kind of changes you are suggesting? > > I know the LibreSSL roadmap includes more plans to improve the API > design to make it more usable. > > Overall, I think LibreSSL is the best option, though there needs to be > some investigation into how easily it can be used for kernel and > boot-loader purposes. Things like libsodium are too narrow in their > focus, and BearSSL is too new. > > Plus the fact that LibreSSL originates from one of the BSDs and has its > backing is a significant advantage, I think. Mostly it originates from OpenSSL. :-) From owner-freebsd-arch@freebsd.org Sun Oct 29 19:13:19 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35D10E4A150; Sun, 29 Oct 2017 19:13:19 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 62F6E635CB; Sun, 29 Oct 2017 19:13:17 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-135ff7000000649f-9a-59f6271477b6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 99.E9.25759.41726F95; Sun, 29 Oct 2017 15:08:05 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9TJ82R1009557; Sun, 29 Oct 2017 15:08:03 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9TJ7wQN022191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Oct 2017 15:08:01 -0400 Date: Sun, 29 Oct 2017 14:07:58 -0500 From: Benjamin Kaduk To: Eric McCorkle Cc: Poul-Henning Kamp , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171029190758.GE26855@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrSuq/i3SYOFfFotFszktvk0HMmZP n8ZksX3zP0aLnk1P2Cw+fON3YPOY8Wk+i8fmpjlsHvd2TGDy+LR/MlsASxSXTUpqTmZZapG+ XQJXxrZV71kK2tgqfrz+y97A+JKli5GTQ0LAROLo66OMXYxcHEICi5kkpnz9yQrhbGSUeNNx jhnCucok0Xj6EVCGg4NFQFXi0rFUkG42ATWJx3ubwcIiAhoS83cLgpQzCyxjkrjy9QwjSI2w gIzEwbOXmEBsXqBtJ/fsg5p5nVniVM8VqISgxMmZT8BOYhbQkrjx7yUTyFBmAWmJ5f84QMKc As4S686cZwOxRQWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtL LdI118vNLNFLTSndxAgKb3YXlR2M3T3ehxgFOBiVeHgFNL5GCrEmlhVX5h5ilORgUhLl3Xf+ U6QQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4vct8ihXhTEiurUovyYVLSHCxK4rzbgnZFCgmk J5akZqemFqQWwWRlODiUJHi11IAaBYtS01Mr0jJzShDSTBycIMN5gIYHgtTwFhck5hZnpkPk TzEac9x4eP0PE8ezma8bmIVY8vLzUqXEeTtBSgVASjNK8+CmgVKURPb+mleM4kDPCfMqglTx ANMb3LxXQKuYgFZpSH4BWVWSiJCSamBcpZXbovTy1ttNh0v+G16/2yvz5tLy2/YHd840VcgV +N39cUZh2eucqx8O9zTsC2DRfD/d4eN2H+2jghLvAvXEbq/ecfZxxDEB0elXjU8fYJK9KvX8 KpuRbdFkhqu8tXfU0zTnz3+gsv4ad5HuS4UTt/JfrV3Wy54d7NKVy17EfrrAbVNyn4usEktx RqKhFnNRcSIAXZPVuiwDAAA= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 19:13:19 -0000 On Sat, Oct 28, 2017 at 08:36:01PM -0400, Eric McCorkle wrote: > On 10/28/2017 09:15, Poul-Henning Kamp wrote: > > -------- > > In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: > > > >> I would say that the 1.1.x series is less bad, especially on the last count, > >> but don't know how much you've looked at the differences in the new branch. > > > > While "less bad" is certainly a laudable goal for OpenSSL, I hope > > FreeBSD has higher ambitions. > > > > I'm curious about your thoughts on LibreSSL as a possible option. I haven't been following LibreSSL enough to have an informed opinion, but my uninformed opinion was that OpenSSL proper has been proceeding with modernization at a faster pace than LibreSSL. -Ben From owner-freebsd-arch@freebsd.org Mon Oct 30 08:06:13 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25381E56F0D; Mon, 30 Oct 2017 08:06:13 +0000 (UTC) (envelope-from julian@elischer.org) 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 E8B317CBC4; Mon, 30 Oct 2017 08:06:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from Julian-MBP3.local (124-148-77-206.dyn.iinet.net.au [124.148.77.206]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v9U85v2c088182 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 30 Oct 2017 01:06:03 -0700 (PDT) (envelope-from julian@elischer.org) Subject: Re: Crypto overhaul To: Eric McCorkle , Poul-Henning Kamp , Benjamin Kaduk Cc: "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Julian Elischer Message-ID: Date: Mon, 30 Oct 2017 16:05:50 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 08:06:13 -0000 On 29/10/17 8:36 am, Eric McCorkle wrote: > On 10/28/2017 09:15, Poul-Henning Kamp wrote: >> -------- >> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: >> >>> I would say that the 1.1.x series is less bad, especially on the last count, >>> but don't know how much you've looked at the differences in the new branch. >> While "less bad" is certainly a laudable goal for OpenSSL, I hope >> FreeBSD has higher ambitions. >> > I'm curious about your thoughts on LibreSSL as a possible option. what gives any evidence as to it being any better? > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon Oct 30 08:20:10 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82F4EE571AF for ; Mon, 30 Oct 2017 08:20:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 4B8C97D0A3; Mon, 30 Oct 2017 08:20:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 631A0260100; Mon, 30 Oct 2017 09:20:08 +0100 (CET) Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. To: Ian Lepore , Matt Joras , "freebsd-arch@FreeBSD.org" References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> <1509294247.21609.12.camel@freebsd.org> <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> <1509296624.21609.24.camel@freebsd.org> From: Hans Petter Selasky Message-ID: <0fad1391-726d-8215-075d-9411abdf6edb@selasky.org> Date: Mon, 30 Oct 2017 09:17:30 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1509296624.21609.24.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 08:20:10 -0000 On 10/29/17 18:03, Ian Lepore wrote: > Oh.  Right.  Hmmm, I think malloc() is required to support the case > where a handler registers before the static list init is invoked, and I > do think that's a useful feature to preserve.  That means the lists > aren't really static, though, which then makes STATIC a bit out of > place in the new function/macro names. Why not use RCU here, and then update sys/queue.h to be RCU safe? --HPS From owner-freebsd-arch@freebsd.org Mon Oct 30 08:38:18 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3A63E5755A; Mon, 30 Oct 2017 08:38:18 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B71F7D924; Mon, 30 Oct 2017 08:38:18 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x229.google.com with SMTP id a192so10965889pge.9; Mon, 30 Oct 2017 01:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ILTbfrxyBefK62ZgRAyC8zjdVh05jryCHDfAnMPeLxU=; b=O3bW2299AxRU7KFqj8mPaBY9YOGqtMR/wfxvCylDai2luBkQWctg4pbR8SsnfbgyrC gXRi2CJB0xeKeFbV3EEWUqGdeCpr/1lcG8psWl15PKjIIsqhgf+HC8EMbqaIuFPkWIyZ ugtFGh6+TCJeCE/mlkIfazQVYh1f85WSTVhXv9qNC+8l9Mg7ewFXOYgspdVbbfu+gXQ0 lBDKoIW2o+UZYx6b2Bdz7iJUgW5u8Fp/YM2vziOAOnXCcWQxDi5u72eNl7fnOp45nV/U snBROyuj8dHSQ+FjFfk0WBoKGe52cqlqSOhqzzPmcEs9A7JERzRM7SmfoJ3QJkcXFEg/ vyYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ILTbfrxyBefK62ZgRAyC8zjdVh05jryCHDfAnMPeLxU=; b=eT4hG78T4rH3tWEuqSO17TOPHivu8kZ2j5ANQCM7GK/FAKFWTzJYMBefx8rWa21V5t VK4u6DILM3v09O+54/WVjCYHSyYdvhiqifaPtEVPLf31x7VgHvd8Q7Hsm6+hht8mYzBS pIqsLcTNT438U40bogdrqRFIYvjHQltn488+TU8LZwu6NxKUoiZ6OT/M2zZt8yrR1QbH x39I8zATRnoD/GJGKDhuL04EEX02pMUYvYlWYZ5HRxrKlnOEEURIrLRcHcVLw+CDDUMm jVGvNyxq5wBpHpn1bzYRZLhGCPG5omH53Wf5ftkd3giad2DLnW+YQs/zgzzCEJvcA+vk mjLQ== X-Gm-Message-State: AMCzsaVejZTZ/up7F0Viu2zq3z0e/s/L32SuaRuxOdNZscCergC+eOMz y/BINo/OnfHCmDTZiSUDDUwOhexH X-Google-Smtp-Source: ABhQp+RzU9jxfijAUDf6bvVV6rRIQvkVKTn0hBaSqUVne4uyrWUOJhKPzts3iYa4iPQ5y2BWHUt5Dg== X-Received: by 10.84.140.235 with SMTP id 98mr6934987plt.428.1509352697248; Mon, 30 Oct 2017 01:38:17 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id 76sm26981562pfq.4.2017.10.30.01.38.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Oct 2017 01:38:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_0E8A217C-E1ED-42DE-BD64-A66B5FF8FD14"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20171023203952.GB51868@alchemy.franken.de> Date: Mon, 30 Oct 2017 01:38:15 -0700 Cc: Mark Linimon , "A. Wilcox" , Gerald Pfeifer , freebsd-sparc64@FreeBSD.org, freebsd-arch@freebsd.org Message-Id: References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@alchemy.franken.de> <20171023203952.GB51868@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 08:38:18 -0000 --Apple-Mail=_0E8A217C-E1ED-42DE-BD64-A66B5FF8FD14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 23, 2017, at 13:39, Marius Strobl wrote: >=20 > On Sun, Oct 22, 2017 at 10:47:03PM -0700, Ngie Cooper (yaneurabeya) = wrote: >>=20 >>> On Oct 10, 2017, at 14:14, Marius Strobl wrote: >>>=20 >>> On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote: >>>>=20 >>>> All gccs > 4.9 fail to build. Looking at the logs AFAICT the = failure >>>> is a floating-point exception as soon as the first built binary is = run >>>> during the internal testing. >>>=20 >>> The most plausible cause for that is executables and/or dynamic = libraries >>> not installing the user trap handlers as specified by the libc 64 = psABI, >>> i. e. not call __sparc_utrap_setup(). Do the ports GCCs use their = own CRT >>> nowadays? Do they no longer link libc last? Please provide their = linker >>> invocation. Also, please provide the backtrace of a minimal program >>> exhibiting that problem. >>=20 >> An idea occurred to me (after having dealt with building things over, = and over, and over, this weekend): since we can?t rely on the ABI on = ^/head to be stable, why don?t we produce working dynamic/static = toolchains on HEAD-1 in ports, then require them for the areas that = can?t bootstrap (yet, or at all?) with clang? We?ve already done that = with some of our code that?s been deorbited from base (like rsh, etc). I = don?t see why making a toolchain based on a stable ABI for architectures = that will migrate or will be killed off needs to be a huge undertaking = (politically), and needs to hold us back from making progress using a = compiler that implements an almost 7 year old C++ spec. >=20 > To be honest, I've no idea what your proposal has to do with the = above, > what it actually is about or why rsh(1) would be a viable example in > this case given that rsh(1) hardly is a bootstrapping tool. However, > ABI changes (the above wasn't about a change in ABI, btw.) are just > one good example why an external toolchain would be a PITA as system > compiler. Think of when we e. g. turned on TLS in the base compiler > configurations after having added TLS support to rtld(1). The next > buildworld ensured that not only the compiler used TLS, but also that > an rtld(1) capable of TLS will be in place. Now with a similar future > change and an external toolchain built on HEAD - 1, some additional > magic would be needed to ensure that binaries built for HEAD use the > expected ABI and all HEAD components are in sync. >=20 > Generally, I'm fine with moving to an external toolchain for the > system compiler, but only if it will also be the default for x86 > so the life of tier-2 architectures won't become even harder - both > politically and technically - as it is now. (Replying to single-message in thread, since the rest seem to follow the = same flow of expressed confusion) Distilling down my scatterbrained message before: I was suggesting = building a cross-compiler with an appropriate target/host tuple as a = package, then allowing users to install that package, instead of = building the toolchain from scratch every time. This is what you = suggested is being worked on by bapt@. Someone should have realized that gcc 4.2.1 is a dead end at the point = anyhow, and clang will need to be bootstrapped from a c++11 capable = compiler (which gcc 4.2.1 is not by any means), right? Which means that = making binary packages work for the toolchain is a must for 2nd tier = architectures if clang is the target compiler (MK_CLANG_BOOTSTRAP=3D=3Dyes= ), which is the eventual end-goal. Cheers, -Ngie --Apple-Mail=_0E8A217C-E1ED-42DE-BD64-A66B5FF8FD14 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----- iQIzBAEBCgAdFiEE5bk3FaGcY5rvqmb79YOpJmkwhhUFAln25PcACgkQ9YOpJmkw hhXMyw//fRWmIsq7s/Mss/sFxhJcuofiGlFqbOqiMtztbEf5NUX+llTMolcSYL/d 5Hdcndc0mbGfNCaHr12Li6HKZlgsyJt2DPUmNPP86OB1gY9nWiUd0oVp+T/0tury AzwRI3yo9Q/ODQxAXw8j+eJWyVX+vEWw8lPflq4ziKw+s5aWKBPJe53EKd0CxvD4 CpMy2R0JoCdppNVyCBWU5jYMB4WbGSYNIIjINmObj0vmPsQKC6UDnOpOGe5jZ+3i b2+SGSYjEkXIoylGjFpu8V6/PnviRFEwb08+3dWuD4RNYeONA68+N+BAa0TQJMCm DSbjwOaFj2k+mgab7D44dfEiTI6p5ztokCfM/pStRBeSwOW9V0EZ2hk4ZVn8ezAV TZDZ+GTV+oKHzpHQdl9MrJEyiDn8FizgepA7KzEw6iVJ9LPjLTwkFs0STzmQkZbO tRtGiwXkkhJbiUXFJlhrFDFMefUyGhEq1/dgP1UqVmJCDMkTmYOcqp4V0AFtqEeY rYAaGaYeWZZIO44qhxaQxpWgZuZkpvH47rhUcV3iRv/Qtx1LpgDSL/TlNsb7jNQY bhluxWHkjUfr6FaiigVsGW+X+jhJsrUKb2CY6qxLyzRI+FPHlm+taO63sNDPrM0V H7nYXzFK3ut0JrDE8pnhW229dR6W8MM3Wr5t6AKxkK9WGXLbRLU= =0YG3 -----END PGP SIGNATURE----- --Apple-Mail=_0E8A217C-E1ED-42DE-BD64-A66B5FF8FD14-- From owner-freebsd-arch@freebsd.org Mon Oct 30 16:05:11 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2A53E6093C for ; Mon, 30 Oct 2017 16:05:11 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 83755686A8 for ; Mon, 30 Oct 2017 16:05:11 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: f6e36dcf-bd8b-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id f6e36dcf-bd8b-11e7-b50b-53dc5ecda239; Mon, 30 Oct 2017 16:04:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9UG53Vx001351; Mon, 30 Oct 2017 10:05:04 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509379503.21609.103.camel@freebsd.org> Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. From: Ian Lepore To: Hans Petter Selasky , Matt Joras , "freebsd-arch@FreeBSD.org" Date: Mon, 30 Oct 2017 10:05:03 -0600 In-Reply-To: <0fad1391-726d-8215-075d-9411abdf6edb@selasky.org> References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> <1509294247.21609.12.camel@freebsd.org> <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> <1509296624.21609.24.camel@freebsd.org> <0fad1391-726d-8215-075d-9411abdf6edb@selasky.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:05:11 -0000 On Mon, 2017-10-30 at 09:17 +0100, Hans Petter Selasky wrote: > On 10/29/17 18:03, Ian Lepore wrote: > > > > Oh.  Right.  Hmmm, I think malloc() is required to support the case > > where a handler registers before the static list init is invoked, and I > > do think that's a useful feature to preserve.  That means the lists > > aren't really static, though, which then makes STATIC a bit out of > > place in the new function/macro names. > Why not use RCU here, and then update sys/queue.h to be RCU safe? > > --HPS I'm not sure how that suggestion relates to that paragraph, but the code already does use a form of RCU to handle deletion of registered handlers from individual event lists.  It could probably benefit from a rewrite to more fully embrace RCU and use it for insertions as well, but that's beyond the scope of these changes, which are trying to eliminate the worst uses of a global lock at a higher level than maintaining the list for a single event. -- Ian From owner-freebsd-arch@freebsd.org Mon Oct 30 16:39:00 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2E7EE6110B for ; Mon, 30 Oct 2017 16:39:00 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 660066993B; Mon, 30 Oct 2017 16:39:00 +0000 (UTC) (envelope-from matt.joras@gmail.com) Received: by mail-qk0-f171.google.com with SMTP id k123so16923299qke.3; Mon, 30 Oct 2017 09:39:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ujCquv5WrCANSxzvjL5b7OGBE6TMOOw45JiKHdIH4ng=; b=mlXeSYuwz5vAFPzX+tlEsKE2g4U8wceDMzsySyt3bFcQdq7a5HWb93BZDCfBXyY+Zj h3jtOfOTWL8E8OeVtBw5cR6HEBMaL3zC9HyYCKRIjsS6xbkRXranle1VCUtUZ47NiTEQ C3V3aZu87L/qGO81abqMhoyKgKANtnbsN2o46fAaBulHAZvssRTmNuMv4mAqPBKmoOVR ZkvafF5qHtG9iII/D3oxSExyCc3TpPXXe/Fd92VJ+gsra7hDqk+n1aE2NlO+NC+yuNxk Q7/hUzmjjEMhcqIYbWocT4igu+PaZjfnY7zUyu0GT/V6aEiS4R5xiEyZ53f/QXW2rqCu Uu5w== X-Gm-Message-State: AMCzsaU+Hzfp8vEV8cPd56N9rzYUXS/ymXpN3FYc41dtKgYWpkwu+UTQ 56hKsHZP7rMBBIVEpc5r2zxoe7C9 X-Google-Smtp-Source: ABhQp+Q8m39YOSHm69Oq8wdqpYB3eVFBnLB+MYykRdQ9gM0mq2sdHH+Qr+7L7uDLidyCBlVH5qpwQQ== X-Received: by 10.55.38.148 with SMTP id m20mr14438456qkm.151.1509381532364; Mon, 30 Oct 2017 09:38:52 -0700 (PDT) Received: from [192.168.2.123] (174-24-242-218.tukw.qwest.net. [174.24.242.218]) by smtp.gmail.com with ESMTPSA id z55sm10375536qth.24.2017.10.30.09.38.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 09:38:51 -0700 (PDT) Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. To: Ian Lepore , Hans Petter Selasky , "freebsd-arch@FreeBSD.org" References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> <1509294247.21609.12.camel@freebsd.org> <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> <1509296624.21609.24.camel@freebsd.org> <0fad1391-726d-8215-075d-9411abdf6edb@selasky.org> <1509379503.21609.103.camel@freebsd.org> From: Matt Joras Message-ID: <54876119-9262-c15b-d3fe-1220cf7f17f6@FreeBSD.org> Date: Mon, 30 Oct 2017 09:38:49 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1509379503.21609.103.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 16:39:00 -0000 On 10/30/2017 09:05, Ian Lepore wrote: > On Mon, 2017-10-30 at 09:17 +0100, Hans Petter Selasky wrote: >> On 10/29/17 18:03, Ian Lepore wrote: >>> Oh.  Right.  Hmmm, I think malloc() is required to support the case >>> where a handler registers before the static list init is invoked, and I >>> do think that's a useful feature to preserve.  That means the lists >>> aren't really static, though, which then makes STATIC a bit out of >>> place in the new function/macro names. >> Why not use RCU here, and then update sys/queue.h to be RCU safe? >> >> --HPS > I'm not sure how that suggestion relates to that paragraph, but the > code already does use a form of RCU to handle deletion of registered > handlers from individual event lists.  It could probably benefit from a > rewrite to more fully embrace RCU and use it for insertions as well, > but that's beyond the scope of these changes, which are trying to > eliminate the worst uses of a global lock at a higher level than > maintaining the list for a single event. > > -- Ian Agreed. There are all sorts of clever things we can do with a more comprehensive rewrite. It would be a nice place to try out RCU-ish methods of handling object removal without locks. Matt From owner-freebsd-arch@freebsd.org Mon Oct 30 21:11:37 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 959CAE65895; Mon, 30 Oct 2017 21:11:37 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (mx0.esc7.net [IPv6:2604:c400:0:2:72:53:186:20]) (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 5BCD571B31; Mon, 30 Oct 2017 21:11:37 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id B96E946353D; Mon, 30 Oct 2017 16:05:21 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=8.8.178.116; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by mx0.esc7.net (Postfix) with ESMTPS id 4A309461C37 for ; Sat, 28 Oct 2017 03:03:58 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id A56638C837; Sat, 28 Oct 2017 08:03:51 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 76A48672E8; Sat, 28 Oct 2017 08:03:51 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAC5EE5E67A; Sat, 28 Oct 2017 08:03:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7977D6723E; Sat, 28 Oct 2017 08:03:38 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9503027374; Sat, 28 Oct 2017 08:03:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9S83Wap023377; Sat, 28 Oct 2017 08:03:34 GMT (envelope-from phk@phk.freebsd.dk) To: Benjamin Kaduk Subject: Re: Crypto overhaul In-reply-to: <20171028022557.GE96685@kduck.kaduk.org> From: "Poul-Henning Kamp" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> MIME-Version: 1.0 Content-ID: <23375.1509177812.1@critter.freebsd.dk> Date: Sat, 28 Oct 2017 08:03:32 +0000 Message-ID: <23376.1509177812@critter.freebsd.dk> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Cc: Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: B96E946353D.A475F X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=5.001, required 3, autolearn=disabled, FOREIGN_DOMAIN 3.00, HEADER_FROM_DIFFERENT_DOMAINS 0.00, NEW_TLDS 3.50, NEW_TLDS_1 3.50, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:11:37 -0000 -------- In message <20171028022557.GE96685@kduck.kaduk.org>, Benjamin Kaduk writes: >But I think the main issue with OpenSSL in base that was leading to >thoughts about replacing it is the mismatch between FreeBSD release >branch support lifecycles and OpenSSL release branch support lifecycles. That's not why I want OpenSSL gone from the tree. My reason is that I think OpenSSLs architecture, (to the extent you can talk about OpenSSL having one), APIs and the source code are all horrible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon Oct 30 21:20:50 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E03CE65B38; Mon, 30 Oct 2017 21:20:50 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (mx0.esc7.net [IPv6:2604:c400:0:2:72:53:186:20]) (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 208CA72178; Mon, 30 Oct 2017 21:20:50 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id B475B465026; Mon, 30 Oct 2017 16:14:31 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2001:1900:2254:206a::19:2; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) by mx0.esc7.net (Postfix) with ESMTPS id BDB77461B05 for ; Sat, 28 Oct 2017 19:36:23 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 6D8FE79260; Sun, 29 Oct 2017 00:36:15 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 33A0E247D; Sun, 29 Oct 2017 00:36:15 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24D1CE52640; Sun, 29 Oct 2017 00:36:02 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id EE25822B0; Sun, 29 Oct 2017 00:36:01 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 6CDA0176E; Sun, 29 Oct 2017 00:36:01 +0000 (UTC) Subject: Re: Crypto overhaul To: Poul-Henning Kamp , Benjamin Kaduk References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Eric McCorkle Message-ID: Date: Sat, 28 Oct 2017 20:36:01 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <24228.1509196559@critter.freebsd.dk> Content-Language: en-US X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Cc: "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: B475B465026.A2FE4 X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.999, required 3, autolearn=disabled, HEADER_FROM_DIFFERENT_DOMAINS 0.00, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:20:50 -0000 On 10/28/2017 09:15, Poul-Henning Kamp wrote: > -------- > In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: > >> I would say that the 1.1.x series is less bad, especially on the last count, >> but don't know how much you've looked at the differences in the new branch. > > While "less bad" is certainly a laudable goal for OpenSSL, I hope > FreeBSD has higher ambitions. > I'm curious about your thoughts on LibreSSL as a possible option. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon Oct 30 21:34:21 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 931AAE6611B; Mon, 30 Oct 2017 21:34:21 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (rmx0.esc7.net [72.53.186.50]) (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 4983172CF2; Mon, 30 Oct 2017 21:34:20 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id 8DBFA465E05; Mon, 30 Oct 2017 16:27:55 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=8.8.178.116; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by mx0.esc7.net (Postfix) with ESMTPS id 3F0F2461B8E for ; Sun, 29 Oct 2017 18:39:30 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 1D805806F3; Sun, 29 Oct 2017 23:39:27 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CAB866B31C; Sun, 29 Oct 2017 23:39:26 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35D10E4A150; Sun, 29 Oct 2017 19:13:19 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 62F6E635CB; Sun, 29 Oct 2017 19:13:17 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-135ff7000000649f-9a-59f6271477b6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 99.E9.25759.41726F95; Sun, 29 Oct 2017 15:08:05 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9TJ82R1009557; Sun, 29 Oct 2017 15:08:03 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9TJ7wQN022191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Oct 2017 15:08:01 -0400 Date: Sun, 29 Oct 2017 14:07:58 -0500 From: Benjamin Kaduk To: Eric McCorkle Subject: Re: Crypto overhaul Message-ID: <20171029190758.GE26855@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrSuq/i3SYOFfFotFszktvk0HMmZP n8ZksX3zP0aLnk1P2Cw+fON3YPOY8Wk+i8fmpjlsHvd2TGDy+LR/MlsASxSXTUpqTmZZapG+ XQJXxrZV71kK2tgqfrz+y97A+JKli5GTQ0LAROLo66OMXYxcHEICi5kkpnz9yQrhbGSUeNNx jhnCucok0Xj6EVCGg4NFQFXi0rFUkG42ATWJx3ubwcIiAhoS83cLgpQzCyxjkrjy9QwjSI2w gIzEwbOXmEBsXqBtJ/fsg5p5nVniVM8VqISgxMmZT8BOYhbQkrjx7yUTyFBmAWmJ5f84QMKc As4S686cZwOxRQWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtL LdI118vNLNFLTSndxAgKb3YXlR2M3T3ehxgFOBiVeHgFNL5GCrEmlhVX5h5ilORgUhLl3Xf+ U6QQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4vct8ihXhTEiurUovyYVLSHCxK4rzbgnZFCgmk J5akZqemFqQWwWRlODiUJHi11IAaBYtS01Mr0jJzShDSTBycIMN5gIYHgtTwFhck5hZnpkPk TzEac9x4eP0PE8ezma8bmIVY8vLzUqXEeTtBSgVASjNK8+CmgVKURPb+mleM4kDPCfMqglTx ANMb3LxXQKuYgFZpSH4BWVWSiJCSamBcpZXbovTy1ttNh0v+G16/2yvz5tLy2/YHd840VcgV +N39cUZh2eucqx8O9zTsC2DRfD/d4eN2H+2jghLvAvXEbq/ecfZxxDEB0elXjU8fYJK9KvX8 KpuRbdFkhqu8tXfU0zTnz3+gsv4ad5HuS4UTt/JfrV3Wy54d7NKVy17EfrrAbVNyn4usEktx RqKhFnNRcSIAXZPVuiwDAAA= X-Mailman-Approved-At: Sun, 29 Oct 2017 23:39:24 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Cc: "freebsd-security@freebsd.org security" , Poul-Henning Kamp , Ben Laurie , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: 8DBFA465E05.A6C5C X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-1.499, required 3, autolearn=disabled, HEADER_FROM_DIFFERENT_DOMAINS 0.00, NEW_TLDS 3.50, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:34:21 -0000 On Sat, Oct 28, 2017 at 08:36:01PM -0400, Eric McCorkle wrote: > On 10/28/2017 09:15, Poul-Henning Kamp wrote: > > -------- > > In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: > > > >> I would say that the 1.1.x series is less bad, especially on the last count, > >> but don't know how much you've looked at the differences in the new branch. > > > > While "less bad" is certainly a laudable goal for OpenSSL, I hope > > FreeBSD has higher ambitions. > > > > I'm curious about your thoughts on LibreSSL as a possible option. I haven't been following LibreSSL enough to have an informed opinion, but my uninformed opinion was that OpenSSL proper has been proceeding with modernization at a faster pace than LibreSSL. -Ben _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon Oct 30 21:55:01 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13A51E66AB4; Mon, 30 Oct 2017 21:55:01 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (mx0.esc7.net [IPv6:2604:c400:0:2:72:53:186:20]) (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 D3A2B73C12; Mon, 30 Oct 2017 21:55:00 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id 44553462C6E; Mon, 30 Oct 2017 15:42:44 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=8.8.178.116; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by mx0.esc7.net (Postfix) with ESMTPS id ADA82461B84 for ; Thu, 26 Oct 2017 19:29:22 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 3977166CBB; Fri, 27 Oct 2017 00:29:15 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6FD6F959; Fri, 27 Oct 2017 00:29:15 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4B41E56CEF; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 918E86F945; Fri, 27 Oct 2017 00:29:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 7E7A912D3; Fri, 27 Oct 2017 00:29:08 +0000 (UTC) To: "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: Crypto overhaul Message-ID: Date: Thu, 26 Oct 2017 20:29:08 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Language: en-US X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: 44553462C6E.A38B7 X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.999, required 3, autolearn=disabled, HEADER_FROM_DIFFERENT_DOMAINS 0.00, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:55:01 -0000 I was going to wait a bit to discuss this, but it's very pertinent to the trust infrastructure I described earlier this week. There was a good bit of discussion at vBSDCon about a possible crypto overhaul. This is my understanding of the current situation: * Userland crypto support is provided by OpenSSL, of course. My sense is that there's a general dissatisfaction with OpenSSL, but that there's a nontrivial effort required to liberate userland from it. * The kernel has sort of two crypto APIs: crypto and opencrypto. The design of these APIs seems to be something of older hardware crypto architectures and export restrictions. This is difficult to extract from the kernel (and say, embed into the boot loader). * BIOS geli pulled the AES implementation out of opencrypto. This was due in a large part to the size restrictions on BIOS loaders. * As a bridge measure, I've introduced boot_crypto into the EFI loader, in order to support GELI. At vBSDcon, there seemed to be a consensus that this situation is too fragmented. Moreover, it makes life difficult for anyone (like me) who wants to do crypto-related projects. A couple of options were discussed at vBSDcon. The two that seemed to come to the forefront were BearSSL and LibreSSL. There seem to be some advantages and disadvantages both ways: * LibreSSL is mature software with staff and support from another BSD (OpenBSD), they've done some really good work, and have a definite long-term roadmap. I'm not sure to what extent it could be easily embedded into a kernel and bootloader, though. * BearSSL's design seemingly lends itself to acting as a userland, kernel, and bootloader library. On the other hand, it's new (which means it will need to be reviewed by crypto experts and thoroughly tested), and has one developer at this point. I think it's worth discussing and investigating these options further at this point. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon Oct 30 22:55:32 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D7F5E25A95; Mon, 30 Oct 2017 22:55:32 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (mx0.esc7.net [IPv6:2604:c400:0:2:72:53:186:20]) (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 D7C217549B; Mon, 30 Oct 2017 22:55:31 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id A1F88462945; Mon, 30 Oct 2017 16:08:22 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2001:1900:2254:206a::19:2; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) by mx0.esc7.net (Postfix) with ESMTPS id 387CA461A24 for ; Sat, 28 Oct 2017 08:16:15 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 8A5FC1702; Sat, 28 Oct 2017 13:16:10 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5A47F6F337; Sat, 28 Oct 2017 13:16:10 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7118FE43448; Sat, 28 Oct 2017 13:16:03 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4196F30E; Sat, 28 Oct 2017 13:16:02 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 5543C27342; Sat, 28 Oct 2017 13:16:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v9SDFxJF024229; Sat, 28 Oct 2017 13:15:59 GMT (envelope-from phk@phk.freebsd.dk) To: Benjamin Kaduk Subject: Re: Crypto overhaul In-reply-to: <20171028123132.GF96685@kduck.kaduk.org> From: "Poul-Henning Kamp" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> MIME-Version: 1.0 Content-ID: <24227.1509196559.1@critter.freebsd.dk> Date: Sat, 28 Oct 2017 13:15:59 +0000 Message-ID: <24228.1509196559@critter.freebsd.dk> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Cc: Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: A1F88462945.A31A6 X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=5.001, required 3, autolearn=disabled, FOREIGN_DOMAIN 3.00, HEADER_FROM_DIFFERENT_DOMAINS 0.00, NEW_TLDS 3.50, NEW_TLDS_1 3.50, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:55:32 -0000 -------- In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk writes: >I would say that the 1.1.x series is less bad, especially on the last count, >but don't know how much you've looked at the differences in the new branch. While "less bad" is certainly a laudable goal for OpenSSL, I hope FreeBSD has higher ambitions. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon Oct 30 23:15:10 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F6E2E264A1; Mon, 30 Oct 2017 23:15:10 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (mx0.esc7.net [IPv6:2604:c400:0:2:72:53:186:20]) (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 1E6AD762C0; Mon, 30 Oct 2017 23:15:10 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id E90D9464F54; Mon, 30 Oct 2017 16:13:56 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2001:1900:2254:206a::19:2; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) by mx0.esc7.net (Postfix) with ESMTPS id B3689461B84 for ; Sat, 28 Oct 2017 18:31:27 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id C727D6A5A4; Sat, 28 Oct 2017 23:31:18 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3E983FAD; Sat, 28 Oct 2017 23:31:18 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FE22E50747; Sat, 28 Oct 2017 23:31:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 3B66D83D9B; Sat, 28 Oct 2017 23:31:07 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9489D174B; Sat, 28 Oct 2017 23:31:06 +0000 (UTC) Subject: Re: Crypto overhaul To: John Hein , freebsd-arch@freebsd.org, freebsd-security@freebsd.org, freebsd-hackers@FreeBSD.org References: <4207-1509111977-98568@sneakemail.com> From: Eric McCorkle Message-ID: Date: Sat, 28 Oct 2017 19:31:06 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4207-1509111977-98568@sneakemail.com> Content-Language: en-US X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: E90D9464F54.A3255 X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.999, required 3, autolearn=disabled, HEADER_FROM_DIFFERENT_DOMAINS 0.00, RCVD_IN_DNSWL_HI -5.00) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:15:10 -0000 On 10/27/2017 09:46, John Hein wrote: > What's the overhaul goal here? There's basic crypto libraries with > symmetric & assymmetric crypto & hashing (e.g., NaCL, libsodium, > openssl's libcrypto). There's libraries that add support for SSL/TLS > & X.509 certificates and such. There's stuff to support using > crypto hardware (accelerators, secure crypto token storage devices). > > And is the thought to [eventually] replace openssl in base with > something lighter perhaps? > > I assume we're looking for bsd, isc, mit, etc., style licenses only. > Sorry for being slow to reply. There's a couple of goals that seem to be in common here (and which I've seen reflected in the comments to my original posting. * Dissatisfaction with the OpenSSL codebase and its history of vulnerabilities. * Desire to consolidate the crypto implementations, specifically, for a crypto library that can serve userland, kernel, and bootloaders. * In my case, the trust framework stuff I wrote about requires public-key crypto in the kernel and loader, which isn't something the kernel crypto framework can do. * It's also harder to add new ciphers when there's multiple crypto codebases. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Mon Oct 30 23:48:20 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34626E26EAF; Mon, 30 Oct 2017 23:48:20 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: from mx0.esc7.net (rmx0.esc7.net [72.53.186.50]) (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 DD08A77281; Mon, 30 Oct 2017 23:48:19 +0000 (UTC) (envelope-from root@mx0.esc7.net) Received: by mx0.esc7.net (Postfix, from userid 0) id 192E24652AF; Mon, 30 Oct 2017 16:25:18 -0500 (CDT) Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=8.8.178.116; helo=mx2.freebsd.org; envelope-from=owner-freebsd-security@freebsd.org; receiver=bwarriner@esc7.net Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) by mx0.esc7.net (Postfix) with ESMTPS id 0F387461C0D for ; Sun, 29 Oct 2017 13:31:58 -0500 (CDT) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 635B081296; Sun, 29 Oct 2017 18:31:51 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 22F4A3237; Sun, 29 Oct 2017 18:31:51 +0000 (UTC) (envelope-from owner-freebsd-security@freebsd.org) Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0CCBE475D7; Sun, 29 Oct 2017 17:15:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9465D3D4; Sun, 29 Oct 2017 17:15:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qk0-x243.google.com with SMTP id x82so13545215qkb.12; Sun, 29 Oct 2017 10:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KbBIk4wF/ij5htrJk8qDFgL2DO374EEvnIRSz+M4u14=; b=bjSZ1Y5IhkazDMzTcfW2GEKDpV9cpLSj73QkxfldZqtTNn6kyVO6B8JVtaBRWM+N9U 7Wq02fQsjosLL7Jv9fX2ONrakCnz/1IB2nJOKyLjgIbn/zovHvMSs5yVqKrla/IJ7SL4 lxQqIL29Ay+Xn9EI/ERl0Ram6ZpPByr6Jz2UBeGKrXqdyZsavjsuynW1nQp6uFolIU7Q QEHZydTVU9K24bZMmE5NyUMn5Sg3y072y3LXX5HP5qQ5jRsuHaKf6PrtySfL6dHexY/d KJJJQTfoRot9mLAvqu3vZoFxFQiO99Y2OmNrw8U1zujWhZGGOL4uA/0O+tONJ+sbr1r4 u84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KbBIk4wF/ij5htrJk8qDFgL2DO374EEvnIRSz+M4u14=; b=ktaoKyARD/rwJdWMtd8IdWIgveryEkf/iXs7jAkYCVv7Rf8mR0uf3nr8iJEuw263dO 8DMnXRxFz0UfbyVYrt0EjTR+aF5x1cTJJ3fcbEHNQQSw3RspPwS9YZwsQLdg5Rlcl7Dn GzQLOW/rNBw+dFiygTyffCJ7/UlzsSu22hzNxPS0QCEOuQcef6Wcmgg/BfI8rXe4jDOa uY1RHWKLJ7Y/Ua1cKlzcFf3RRyC3tqPZleRqeAQxVnEAO2ah/zG9eMWhKc4uXlN1OXCR aYmIxd257HCtG5Vdb2eOTIjyapQPK5xB76h998k3g0KHKT+gs63YhqofRHEwXkyA1i1H U21A== X-Gm-Message-State: AMCzsaWaSG83MkoKTbep5LstQ16Y/xfjDSUJtVfCflHTqqFhsuPS/hWI dZw8fXhePgrDK8uknLJQqJemDcB1iCz1qNSbJUs= X-Google-Smtp-Source: ABhQp+SHLAgMCXgjFKe2WMS89jNcGetcVG7fne3MoLNveq0lAcg97BCgjl7cLYIPXQbZ377mzsJi5JCKQmyA7tvKe/k= X-Received: by 10.55.197.20 with SMTP id p20mr9680636qki.229.1509297314773; Sun, 29 Oct 2017 10:15:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.22.174 with HTTP; Sun, 29 Oct 2017 10:15:14 -0700 (PDT) In-Reply-To: <61210249-105c-974c-1dae-1837e5969054@metricspace.net> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> <28039.1509260726@critter.freebsd.dk> <61210249-105c-974c-1dae-1837e5969054@metricspace.net> From: Ben Laurie Date: Sun, 29 Oct 2017 17:15:14 +0000 X-Google-Sender-Auth: YL3p4S4Fawfv-h3A9jWw9YR424Y Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle X-Mailman-Approved-At: Sun, 29 Oct 2017 18:31:47 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list Cc: Benjamin Kaduk , "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , bf1783@gmail.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-ESC7-MailScanner-Information: Please contact the ISP for more information X-ESC7-MailScanner-ID: 192E24652AF.A5B23 X-ESC7-MailScanner: Found to be clean X-ESC7-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.889, required 3, autolearn=disabled, DKIM_SIGNED 0.10, HEADER_FROM_DIFFERENT_DOMAINS 0.00, RCVD_IN_DNSWL_HI -5.00, T_DKIM_INVALID 0.01) X-ESC7-MailScanner-From: root@mx0.esc7.net X-Spam-Status: No X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:48:20 -0000 On 29 October 2017 at 15:17, Eric McCorkle wrote: > On 10/29/2017 09:46, bf wrote: >> On 10/29/17, Poul-Henning Kamp wrote: >>> -------- >>> In message , Eric >>> McCorkl >>> e writes: >>>> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>>>> -------- >>>>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>>>> writes: >>>>> >>>>>> I would say that the 1.1.x series is less bad, especially on the last >>>>>> count, >>>>>> but don't know how much you've looked at the differences in the new >>>>>> branch. >>>>> >>>>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>>>> FreeBSD has higher ambitions. >>>>> >>>> >>>> I'm curious about your thoughts on LibreSSL as a possible option. >>> >>> It retains the horrible APIs, so the potential improvement is finite. >>> >> >> OpenBSD started the task of making OpenSSL easier to use by adding >> things like libtls >> >> (see https://man.openbsd.org/tls_init ) >> >> on top of their backwards-compatible libssl. There are similar >> efforts in other libraries like NaCl and its forks, such as libsodium >> ( cf. https://nacl.cr.yp.to/features.html and >> https://www.gitbook.com/book/jedisct1/libsodium/details ). Are these >> the kind of changes you are suggesting? > > I know the LibreSSL roadmap includes more plans to improve the API > design to make it more usable. > > Overall, I think LibreSSL is the best option, though there needs to be > some investigation into how easily it can be used for kernel and > boot-loader purposes. Things like libsodium are too narrow in their > focus, and BearSSL is too new. > > Plus the fact that LibreSSL originates from one of the BSDs and has its > backing is a significant advantage, I think. Mostly it originates from OpenSSL. :-) _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Tue Oct 31 00:56:29 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8E4DE3AEEB for ; Tue, 31 Oct 2017 00:56:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F41F7E0A7 for ; Tue, 31 Oct 2017 00:56:29 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 8C3631889C for ; Tue, 31 Oct 2017 00:56:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 8BD58A6DD for ; Tue, 31 Oct 2017 00:56:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id YKQ14E1RQ3bf for ; Tue, 31 Oct 2017 00:56:23 +0000 (UTC) Subject: Re: [Build] Enabling automatic object directory creation DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com EF113A6D8 From: Bryan Drewery To: "freebsd-arch@freebsd.org" References: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <47ac7412-2925-fc04-0759-ea854f464007@FreeBSD.org> Date: Mon, 30 Oct 2017 17:56:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iM3pBKMl9C07AugfumemG75qhaGOFIomg" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 00:56:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iM3pBKMl9C07AugfumemG75qhaGOFIomg Content-Type: multipart/mixed; boundary="LNEmv8FP0cgOhT9VgwhB0tXaVOBbiombl"; protected-headers="v1" From: Bryan Drewery To: "freebsd-arch@freebsd.org" Message-ID: <47ac7412-2925-fc04-0759-ea854f464007@FreeBSD.org> Subject: Re: [Build] Enabling automatic object directory creation References: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> In-Reply-To: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> --LNEmv8FP0cgOhT9VgwhB0tXaVOBbiombl Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/25/2016 11:20 AM, Bryan Drewery wrote: > For in-tree source builds only, I would like to make it so that 'make' > in a subdirectory would automatically create the object directory. Thi= s > would naturally extend to buildworld/buildkernel as well with some > tweaks. I already am nearly done with adding this in for buildworld an= d > was going to just make it happen since the 'make obj' tree-walk is a > waste of time. It is very error-prone to not automatically create an > object directory when building in a subdirectory as it may look for > files in the wrong place. So I would prefer to add it everywhere inste= ad. >=20 > What is the impact of this feature? >=20 > Keep in mind this would *only affect in-tree builds, not ports*. >=20 > We would need to move the 'default' MAKEOBJDIRPREFIX from > Makefile/Makefile.inc1 into share/mk/sys.mk. It would only be > overridable from environment and make argument, but also > /etc/src-env.conf (I think). This restriction is already in place. I > would have to move the assertion for this out of /Makefile and into > sys.mk. Now when I say sys.mk I really mean something like > src.sys.env.mk. which is hidden in a way to only impact in-tree builds.= >=20 > The feature is named 'WITH_AUTO_OBJ'. Enabling this by default means > that the only way to disable it is to add WITHOUT_AUTO_OBJ=3Dyes to > environment, make argument or /etc/src-env.conf. >=20 > There are times when building in a directory without an object directoy= > makes sense, but for the vast majority of people they likely have done = a > buildworld already and are trying to build in a subdirectory to test > something further. If they pulled down new revisions then it is > possible that this new directory did not get a 'make obj' tree-walk. >=20 > A side topic is changing the default MAKEOBJDIR such that it always use= s > ${MAKEOBJDIRPREFIX}/${SRCTOP}/${TARGET}.${TARGET_ARCH}/${RELDIR}. Doin= g > this is far simpler if I can just use WITH_AUTO_OBJ everywhere. This i= s > discussed a bit in https://reviews.freebsd.org/D3711. It would give > directories such as: /usr/obj/usr/src/amd64.amd64/bin/sh. It would kee= p > all universe/cross-builds inside of /usr/obj/usr/src and allow more > easily cleaning up object trees with multiple checkouts. This object > tree pattern is what the DIRDEPS_BUILD uses as well and has been quite > handy. I would extend the DIRDEPS_BUILD 'make destroy' and 'make > destroy-arch', to the normal build, to cleanup the entire object tree > for the object directory and the specified target.target_arch respectiv= ely. >=20 >=20 I have 2 reviews for this: Changing the default OBJDIR to be like: /usr/obj//./ is at https://reviews.freebsd.org/D12840 Enabling AUTO_OBJ if the wanted MAKEOBJDIR is writable is at https://reviews.freebsd.org/D12841 --=20 Regards, Bryan Drewery --LNEmv8FP0cgOhT9VgwhB0tXaVOBbiombl-- --iM3pBKMl9C07AugfumemG75qhaGOFIomg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJZ98okAAoJEDXXcbtuRpfPKTYH+weLjDZHvIn9O/ZsafnCaZfB Nu342H3WTongJaln4VS9lWItvPBgWSGIj1x2CQsMgiDPyQkr4yPPrjgewIXTJy6C +0FEAGrFkuNyGHn76drceYtl1KpFuKr8S4tEvkZZJc3IXt1H+/S1V7dD4L+ljnz7 E0m4c3coudPXYMT7tuawQcveBaHq79cgfm4RxREUswMK/NhCUZcgn4o3bCqdKJRF LSZmlR4MdaupxaYQRRbpyU7oW6COMkVMRsPfA9e5RxiWKdxufOH7QL4Uv6INhDop hBF4zXFWOlbDrqtxEqPjyUOicPoDvz4pLzpdBSXrmGXeelaNf3d2MlkY0N6wXjk= =kfCQ -----END PGP SIGNATURE----- --iM3pBKMl9C07AugfumemG75qhaGOFIomg-- From owner-freebsd-arch@freebsd.org Tue Oct 31 10:05:15 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C657E5415D for ; Tue, 31 Oct 2017 10:05:15 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 513A16C819; Tue, 31 Oct 2017 10:05:15 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22a.google.com with SMTP id f8so19944442qta.5; Tue, 31 Oct 2017 03:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=klfrzuCLyyxZegIauwCuagWJDGwvyTnc1kN1VPYYoyI=; b=L32wECerl7c6Xsx4/gD7xfyQ3LnWSwDmm9lVc4y5NnTflHzmxqAFg5Oc4RnBpPAGJi oSO6FGQnjv927vwawHxkkAe9ED9/GGi6liPknc/+Wd02qVENpa+OJAc1Tcd65G8rUDvG OuBn1sOf2wNpvFUnPmWlzJY3S6E7kDEBBNrIOsGUO+vrBPPi81s7N2juKtFXCO62KzG/ Y/+pAbsCBNfOjiNXcnZ3Z06LUOqwxMxopn0kXM+cgNbmDTRJeU9L5ZQqajKiNpnuRTCP CrCFbQFP5WajklD1QCDNAt+KCR7IaRjMY4+K9KG2izs66iPN59+XMv65OT+9a/s+L83T 4Shg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=klfrzuCLyyxZegIauwCuagWJDGwvyTnc1kN1VPYYoyI=; b=jKejeNKmL27LwiyLB/AYfgd/WlPr6xNQY6j8IFGMqVoZ9PiGoyjBmai9DOz4obsS7J QNLlpPWfkgmiWJWhu5rIH5BPDHPsq6SiFpcn5hw4hCAZ3B21FsixmBkdIknOwyOC/eVy fDmr4YhYDur2K1bOxSZJRk+eZjTzAUDJn/N93cpO1KjmOlXaGoDjxwbF52AWk5nKeZ0I ++OdjjOI7bR4B7P5JgdDjsJ6EJgcligP0IAafzygF6xnoyqepCg0+fm4I3l/Obk3Rnlk P19gHFLrrKQKqoQGgUAW63jEXapY8dKhh85Y53Rc1Ed/XyfZMSN9TnWRLWwLNdAsuEP2 08fA== X-Gm-Message-State: AMCzsaVOll4vSFIVpD0KSDKI37J/OFvU69I94CIRMviNjtHDnR3Lv5CP lmSTLNSjsh7jQoQY8FMBTwt+XJNCuXWzTwZA3Hg= X-Google-Smtp-Source: ABhQp+Rse0PgNd2NhZS+j0Q3LF3HRP7BtMgKvcNCq1qv/BTP+lLmU5x1qltGKwexyjyy77AD8AWgDstnpazKhykCz+I= X-Received: by 10.237.33.186 with SMTP id l55mr1914747qtc.71.1509444314202; Tue, 31 Oct 2017 03:05:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.52.198 with HTTP; Tue, 31 Oct 2017 03:05:13 -0700 (PDT) In-Reply-To: <20171031095920.5jn7ib63ofdm7wwf@mguzik> References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> <1509294247.21609.12.camel@freebsd.org> <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> <1509296624.21609.24.camel@freebsd.org> <0fad1391-726d-8215-075d-9411abdf6edb@selasky.org> <1509379503.21609.103.camel@freebsd.org> <54876119-9262-c15b-d3fe-1220cf7f17f6@FreeBSD.org> <20171031095920.5jn7ib63ofdm7wwf@mguzik> From: Mateusz Guzik Date: Tue, 31 Oct 2017 11:05:13 +0100 Message-ID: Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. To: Matt Joras Cc: Ian Lepore , Hans Petter Selasky , "freebsd-arch@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 10:05:15 -0000 On Tue, Oct 31, 2017 at 10:59 AM, Mateusz Guzik wrote: > On Mon, Oct 30, 2017 at 09:38:49AM -0700, Matt Joras wrote: > > On 10/30/2017 09:05, Ian Lepore wrote: > > > On Mon, 2017-10-30 at 09:17 +0100, Hans Petter Selasky wrote: > > >> On 10/29/17 18:03, Ian Lepore wrote: > > >>> Oh. Right. Hmmm, I think malloc() is required to support the case > > >>> where a handler registers before the static list init is invoked, > and I > > >>> do think that's a useful feature to preserve. That means the lists > > >>> aren't really static, though, which then makes STATIC a bit out of > > >>> place in the new function/macro names. > > >> Why not use RCU here, and then update sys/queue.h to be RCU safe? > > >> > > >> --HPS > > > I'm not sure how that suggestion relates to that paragraph, but the > > > code already does use a form of RCU to handle deletion of registered > > > handlers from individual event lists. It could probably benefit from a > > > rewrite to more fully embrace RCU and use it for insertions as well, > > > but that's beyond the scope of these changes, which are trying to > > > eliminate the worst uses of a global lock at a higher level than > > > maintaining the list for a single event. > > > > > > -- Ian > > > > Agreed. There are all sorts of clever things we can do with a more > > comprehensive rewrite. It would be a nice place to try out RCU-ish > > methods of handling object removal without locks. > > The current EH code delightet us long enough. It has to be dropped. > > delighted even > I don't think RCU (which we don't have anyway, apart from a rather poor > substitute) is suitable for use here. > > First off, vast majority of all lists are never going away and most > callbacks are not going away either. > > The gist is that in the worst case we can use rmlocks, which boil down > to per-cpu locks. Employing rcu would require refing and unrefing which > slows things down due to cacheline bounces. > > So here is is roughly how I see it: > 1. always-existing list + never-removed callbacks > > Note that here callbacks can be *added*, but never removed. If > implemented as a list it is really trivial with what hps referred to as > "rcu safe" macros - you set everything up and update the ->next pointer > last. Then the list is always safe to traverse with the worst case being > you finished before the addition of the next element completed. But you > never see half-constructed anything. > > 2. always-existing list + removable callbacks > > They can be stored *separately* to never-removed callbacks. Here is > where rmlocks come to play. An important detail is that the current eh > mechanism allows deregeistration to be performed while *within* a > callback. I think that's a rather weird-ass feature which needs to be > dropped from the replacement. I don't see any added value and I see > *loss* in that things have to get refed/unrefed and stuff relocked. > > 3. lists which can disappear > > Once more rmlocks. > I can't stress enough that writing to shared areas is a major performance problem on multicore systems. Code which does it for no good reason is an excellent candidate for a revamp. I don't see how said writing can be avoided while providing the current EH guarantee that things can be deregistered from the callback. One more reason to create a *new* mechanism from scratch and let the old code die off. -- Mateusz Guzik From owner-freebsd-arch@freebsd.org Tue Oct 31 11:48:41 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A517CE56992; Tue, 31 Oct 2017 11:48:41 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 792AB71232; Tue, 31 Oct 2017 11:48:41 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 123DA1DDD; Tue, 31 Oct 2017 11:48:41 +0000 (UTC) Subject: Re: Crypto overhaul To: Julian Elischer , Poul-Henning Kamp , Benjamin Kaduk Cc: "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , Ben Laurie , "freebsd-hackers@freebsd.org" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Eric McCorkle Message-ID: Date: Tue, 31 Oct 2017 07:48:40 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 11:48:41 -0000 On 10/30/2017 04:05, Julian Elischer wrote: > On 29/10/17 8:36 am, Eric McCorkle wrote: >> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>> -------- >>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>> writes: >>> >>>> I would say that the 1.1.x series is less bad, especially on the >>>> last count, >>>> but don't know how much you've looked at the differences in the new >>>> branch. >>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>> FreeBSD has higher ambitions. >>> >> I'm curious about your thoughts on LibreSSL as a possible option. > > what gives any evidence as to it being any better? At least as about its first year and a half, LibreSSL had a markedly better track record than OpenSSL (zero high-severity CVEs vs 5 from OpenSSL, about half as many mid- and low-security CVEs). From owner-freebsd-arch@freebsd.org Tue Oct 31 12:09:45 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15F16E5800F; Tue, 31 Oct 2017 12:09:45 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD0DC72793; Tue, 31 Oct 2017 12:09:44 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qk0-x230.google.com with SMTP id o187so20084086qke.7; Tue, 31 Oct 2017 05:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wpRNTOTDupguLPkaIn3o1twQ9MjBa86KKEqmRsmt7js=; b=cKcPV2Asr7MwWu9I+hxbTE1NOr7BGHsM/n+mIykg+K4xW12obc9mwkuS3R9YCXHmo7 DXfiKTWgteC1a1a3hVXLznmUW4HZtK4mQWyf5TAGFgag8ks/EEd+aczFAdv3tgMZ9lG3 xTH+Pm7XvBH8uRAHAcW/yTilB3Hx4pt17TTUa1OWYgOE3Rulr5+SelM0izpbjS41mxEO 71+MhjPcBy/xpwIYDsZkoe4iwrJS7VwELB8dCC84dPCCB471qiatkijyjawV5YjLo7M6 VPBRbzhOb/wEqX2ww5FvFB+OTtgI7TSVy14mXgUV75dBS9MY8axTHqeQXaqUXUeuMo3w I5xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wpRNTOTDupguLPkaIn3o1twQ9MjBa86KKEqmRsmt7js=; b=gYaIFxRu3fYMiaNyeGFboOgI8HAas6XN1tF8VmYCeecamwT/h94WH+JEjvvlrwhD0f NpvPfrIFhissZW9fHDD1sgys7XZOYcwoenP2C7OKimyaMG6HWdlIKSRfI9p3LUSq5b6E pSbO/SklqIlODKFw5Zpmcsu4x5GzK2VfaZMq9HHOCNBpkK/Xqho6AD4DcP4T9nIakQzQ Iug+vNEkPBrO/NyEJpIXcFb0SG9zuBPmt/lDNodAKbniTeq0pvFeHVadDsCMPIc0ByuH kvX9k3UhIC8PXUm1Kh6lxTt04wWbP7Y6WM64bdWrYEeZzQt5pk7bVfjAWxWg0mSjQKG7 PW/A== X-Gm-Message-State: AMCzsaXct582tlfHKXWHAkm3b6RBgqwOdilGh1wDX7JKGK+AVKlF1zbK ljQCnf2wj2uZN/R1gWrRKTo2h6R9JO/cr4uNbJB08yGD X-Google-Smtp-Source: ABhQp+S/TDvaQXKiQvwlsgaEFRMjMkBunKHz2I5lieLwYWeDPn0UOyoyqZnA9EYCZc+7/pl6ik0NrAK22N/gfYyEuyo= X-Received: by 10.55.39.145 with SMTP id n139mr2379578qkn.70.1509451783826; Tue, 31 Oct 2017 05:09:43 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Tue, 31 Oct 2017 05:09:43 -0700 (PDT) In-Reply-To: References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Ben Laurie Date: Tue, 31 Oct 2017 12:09:43 +0000 X-Google-Sender-Auth: OojgfRKA5KJ3YvZD77rXtAuGFCc Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: Julian Elischer , Poul-Henning Kamp , Benjamin Kaduk , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 12:09:45 -0000 On 31 October 2017 at 11:48, Eric McCorkle wrote: > On 10/30/2017 04:05, Julian Elischer wrote: >> On 29/10/17 8:36 am, Eric McCorkle wrote: >>> On 10/28/2017 09:15, Poul-Henning Kamp wrote: >>>> -------- >>>> In message <20171028123132.GF96685@kduck.kaduk.org>, Benjamin Kaduk >>>> writes: >>>> >>>>> I would say that the 1.1.x series is less bad, especially on the >>>>> last count, >>>>> but don't know how much you've looked at the differences in the new >>>>> branch. >>>> While "less bad" is certainly a laudable goal for OpenSSL, I hope >>>> FreeBSD has higher ambitions. >>>> >>> I'm curious about your thoughts on LibreSSL as a possible option. >> >> what gives any evidence as to it being any better? > > At least as about its first year and a half, LibreSSL had a markedly > better track record than OpenSSL (zero high-severity CVEs vs 5 from > OpenSSL, about half as many mid- and low-security CVEs). Not getting CVEs doesn't mean not having the issues: https://marc.info/?l=openbsd-announce&m=140752800525709. From owner-freebsd-arch@freebsd.org Tue Oct 31 12:24:34 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BB3BE58809; Tue, 31 Oct 2017 12:24:34 +0000 (UTC) (envelope-from swall@redcom.com) Received: from smtp1.redcom.com (smtp1.redcom.com [192.86.3.143]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB6C734D3; Tue, 31 Oct 2017 12:24:33 +0000 (UTC) (envelope-from swall@redcom.com) Received: from localhost (localhost [127.0.0.1]) by smtp1.redcom.com (Postfix) with ESMTP id E42CCA043; Tue, 31 Oct 2017 08:24:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at redcom.com Received: from smtp1.redcom.com ([127.0.0.1]) by localhost (smtp1.redcom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmeTgvPpBMCa; Tue, 31 Oct 2017 08:24:25 -0400 (EDT) Received: from pie.redcom.com (pie [192.168.33.15]) by smtp1.redcom.com (Postfix) with ESMTP id 4B5DFA02A; Tue, 31 Oct 2017 08:24:25 -0400 (EDT) Received: from exch-02.redcom.com (exch-02.redcom.com [192.168.32.9]) by pie.redcom.com (8.11.7p1+Sun/8.10.2) with ESMTP id v9VCO0l29495; Tue, 31 Oct 2017 08:24:25 -0400 (EDT) Received: from exch-02.redcom.com (fd00::ccaa:c259:22f8:6f4b) by exch-02.redcom.com (fd00::ccaa:c259:22f8:6f4b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 31 Oct 2017 08:24:00 -0400 Received: from exch-02.redcom.com ([fe80::ccaa:c259:22f8:6f4b]) by exch-02.redcom.com ([fe80::ccaa:c259:22f8:6f4b%12]) with mapi id 15.00.1178.000; Tue, 31 Oct 2017 08:24:00 -0400 From: "Wall, Stephen" To: "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: RE: Crypto overhaul Thread-Topic: Crypto overhaul Thread-Index: AQHTT1k1W13dziFDt0aDYDljK8GQJKL4ZliAgABmMICAAF5RAIAASuEAgAAMbICAAL3/gIACEAMAgAHQlwD//8TWEA== Date: Tue, 31 Oct 2017 12:23:59 +0000 Message-ID: References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.84.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 12:24:34 -0000 > At least as about its first year and a half, LibreSSL had a markedly > better track record than OpenSSL (zero high-severity CVEs vs 5 from > OpenSSL, about half as many mid- and low-security CVEs). Are any of these relevant to the crypto module? Or are they all only appli= cable to the SSL protocol? As I understand the discussion so far, the goal is to unify all the dispara= te crypto pieces in the base system. That could certainly be done using Op= enSSLs libcrypto, and let users select their SSL provider from the ports tr= ee. -spw From owner-freebsd-arch@freebsd.org Tue Oct 31 23:34:27 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE0B0E4434C; Tue, 31 Oct 2017 23:34:27 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 0638B6927C; Tue, 31 Oct 2017 23:34:26 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 772BB1FBA; Tue, 31 Oct 2017 23:34:26 +0000 (UTC) Subject: Re: Crypto overhaul To: freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" , "freebsd-security@freebsd.org security" References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> <20171028123132.GF96685@kduck.kaduk.org> <24228.1509196559@critter.freebsd.dk> From: Eric McCorkle Message-ID: <1adbe576-2610-573b-f555-3b1a537f25e0@metricspace.net> Date: Tue, 31 Oct 2017 19:34:26 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 23:34:28 -0000 On 10/31/2017 08:23, Wall, Stephen wrote: >> At least as about its first year and a half, LibreSSL had a markedly >> better track record than OpenSSL (zero high-severity CVEs vs 5 from >> OpenSSL, about half as many mid- and low-security CVEs). > > Are any of these relevant to the crypto module? Or are they all only applicable to the SSL protocol? > > As I understand the discussion so far, the goal is to unify all the disparate crypto pieces in the base system. That could certainly be done using OpenSSLs libcrypto, and let users select their SSL provider from the ports tree. That's already how things work, but it doesn't provide a viable solution for kernel and boot loader APIs. There's apparently been at least one attempt to embed OpenSSL into the kernel, to no avail.