From owner-freebsd-arch@freebsd.org Wed Aug 30 22:43: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 B0C13E0BEFE for ; Wed, 30 Aug 2017 22:43:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from bat.oak.relay.mailchannels.net (bat.oak.relay.mailchannels.net [23.83.215.13]) (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 6F757833DE for ; Wed, 30 Aug 2017 22:43:19 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 13AD120165A for ; Wed, 30 Aug 2017 22:43:18 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.126.149]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 665A22018E5 for ; Wed, 30 Aug 2017 22:43:17 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.107.195]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Wed, 30 Aug 2017 22:43:18 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-White-Thread: 12f0e50e5f41445b_1504132997884_2093115617 X-MC-Loop-Signature: 1504132997884:2348899577 X-MC-Ingress-Time: 1504132997883 X-MHO-User: 966682c0-8dd4-11e7-83af-a91f44540cb3 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 966682c0-8dd4-11e7-83af-a91f44540cb3; Wed, 30 Aug 2017 22:43:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v7UMh3nd004637; Wed, 30 Aug 2017 16:43:03 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1504132983.56799.90.camel@freebsd.org> Subject: Re: Import BearSSL ? (Adding verification to loader) From: Ian Lepore To: "Simon J. Gerraty" , freebsd-arch@freebsd.org Cc: gtetlow@freebsd.org, Ed Maste , Steve Kiernan , Baptiste Daroussin , Toomas Soome , Allan Jude , Edward Tomasz =?iso-8859-2?Q?Napiera=B3a?= Date: Wed, 30 Aug 2017 16:43:03 -0600 In-Reply-To: <24256.1504130148@kaos.jnpr.net> References: <44449.1497382261@kaos.jnpr.net> <24256.1504130148@kaos.jnpr.net> 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: quoted-printable 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: Wed, 30 Aug 2017 22:43:19 -0000 On Wed, 2017-08-30 at 14:55 -0700, Simon J. Gerraty wrote: > Hi, >=20 > Background: >=20 > I've been adding what amounts to a mini "verified exec" to the freebsd > loader for use in Junos. >=20 > What this means is that the loader verifies the kernel and all the > modules before loading them, and can reject anything for which a > registered fingerprint (eg. sha1 hash) does not match. >=20 >=20 [...] > The question is what to do - for upstreaming any of this. > Assuming of course anyone is interested in this functionality. >=20 > The changes to the loader itself are trivial. > Most of the code is in libve (naming stuff is hard) which handles > fingerprint loading, lookup and of course verifying signatures using > code from; libbearssl - which is just a reachover build of BearSSL. >=20 > I have it setup such that BearSSL need not be part of the tree at all s= o > there is no burning need to import it; lib/libbearssl will simply not > build if ${BEARSSL} isn't defined and pointing to a BearSSL tree. >=20 > From an internal paper-work point-of-view, contrib/bearssl is attractiv= e > to me ;-), but it could just as easily be in ports no where at all. >=20 > If it were in contrib, then it would be feasible to leverage it for > other uses in the loader that currently use libmd etc for hashing. >=20 > Discuss ? >=20 > Thanks > --sjg We need this exact feature (verification of kernel and modules) for an upcoming product at work. =A0Including the library code in contrib certainly sounds attractive to me, too. I wouldn't be surprised if interest in this goes beyond those of us building embedded appliances. -- Ian