From owner-freebsd-arch@freebsd.org Sun Oct 22 01:34:16 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 451E2E40AB3 for ; Sun, 22 Oct 2017 01:34:16 +0000 (UTC) (envelope-from allianceconsulting001001@gmail.com) Received: from cat-white-4eb35278374174b5.znlc.jp (cat-white-4eb35278374174b5.znlc.jp [154.34.8.187]) (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 16FFD72DE4 for ; Sun, 22 Oct 2017 01:34:16 +0000 (UTC) (envelope-from allianceconsulting001001@gmail.com) Received: from [103.207.36.242] (unknown [103.207.36.242]) by cat-white-4eb35278374174b5.znlc.jp (Postfix) with ESMTPA id CA6F0F9EB for ; Sun, 22 Oct 2017 09:47:50 +0900 (JST) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Subject: [SPAM] Funding Information To: freebsd-arch@FreeBSD.org From: Swiss Consultant Ch Date: Sat, 21 Oct 2017 17:47:46 -0700 Reply-To: info@alliancefinancialconsultant.com X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 X-Drweb-SpamState: yes X-Drweb-SpamScore: 500 X-DrWeb-SpamReason: gggruggvucftvghtrhhoucdtuddrgedttddrvddvucetufdoteggodetrfcurfhrohhfihhlvgemuceonhhonhgvqeenuceurghilhhouhhtmecupfdsteenucgohfhorhgsihguuggvnhfgmhgrihhlucdlhedttddm 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, 22 Oct 2017 01:34:16 -0000 Hello. Good day to you. My name is .Chahal karnail chahal am the financial director for Alliance co= nsulting group, an investment / financial consulting company. We sent you an email yesterday about project funding as we have investors r= eady to finance good project with positive ROI. Do let me know if you received it so further details can be advised. Thank you and kindest regards Mr.Chahal karnail chahal Chief Financial Consultant Alliance Group Email : info@alliancefinancialconsultant.com From owner-freebsd-arch@freebsd.org Sun Oct 22 22:14: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 9C3FBE37B81; Sun, 22 Oct 2017 22:14:45 +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 7967E770EB; Sun, 22 Oct 2017 22:14:45 +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 CD4FE2D07; Sun, 22 Oct 2017 22:14:40 +0000 (UTC) To: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org From: Eric McCorkle Subject: Trust system write-up Message-ID: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> Date: Sun, 22 Oct 2017 18:14:40 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 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, 22 Oct 2017 22:14:45 -0000 Hello everyone, The following is a write-up of my current design for a public-key trust system: https://www.metricspace.net/files/freebsd_trust.pdf Some of you are certainly familiar with some or all of this; I've discussed parts of it before on -hackers and -security, and I discussed it in greater detail in BoF sessions at vBSDCon. It seems things are heating up in this direction, so I'd like to get this out there and get discussion and feedback. I plan on undertaking work on this in the very near future, especially since the commit-train for GELI EFI is ready to arrive in HEAD. A bit about the format: this is sort of the "meat" of what I hope will be a paper some day, but it's still an initial draft. Moreover, it talks about things I'm planning as if they exist, mainly because I don't want to have to go back and rewrite everything in the future. In reality, most of what I talk about is just a proposal at this point, with a few bits being implemented as a PoC here and there. Please read and consider the designs I've proposed. I welcome any feedback and suggestions. I'll give it a week minimum from today before I resume any work on this stuff. Note: Apologies for the external link; I had originally included this as an attachment, but it was too large. From owner-freebsd-arch@freebsd.org Sun Oct 22 22:31:42 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 86694E3833F for ; Sun, 22 Oct 2017 22:31:42 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 44100779FA for ; Sun, 22 Oct 2017 22:31:42 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt0-x229.google.com with SMTP id 8so24129997qtv.1 for ; Sun, 22 Oct 2017 15:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bSyhe9uYPpe7TOlfCzaPDkrNgbYDdmbbs/LdFqmQ8Sk=; b=e4hbPJ7fOT9GE8X35njVH+ahYhtbSVCkhIY6nkC03CXws/BCRJ0T+RD7nMBS5RIzfo yUBzc39yerQu5Ym95YRwcku9uBRYcv1FN5/j34xxnNmsRvGq3oqvnotANbabplzNdVot jpNH5yojNwwpT7YLAfNP42rJqekWPB0AZ3j6bLLs2Lr2t0Gsqr9SoX2oMyOWwueLh11U JwrGW/Pji8namtmd45JT3j6O8OSwO1tv7IbxPXfltPKXI9nM5PENPZKQCrO/YSNFP7et os1LAIvQ1P+Bv2iscfMRf6LY9FClCRYzY9GDMGMrUEUffauMXbT2jgWAdlh21tvQR4qx Ggcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bSyhe9uYPpe7TOlfCzaPDkrNgbYDdmbbs/LdFqmQ8Sk=; b=F4mj/K+q2/OaFC8OSX8hJqrnFhHuXgS+qXrn3vrGug0lEDOEsMA4Hpk1tFxLElU31V +5Hk5n5Zi2uUIxbrisDBCynjXJMzXU2H8bpKWWAZUNfZmQGNEJwec5TA1mTNov1o7AW8 3qS3WakQPOVIrXb6Ku9MFZR8+zcLqjzzmVhkRINjaMVzNSFEzV536RrfwxtSJ7S/pcIv KTxWXj+wyWGQ+JVGsVr8MDvT0jcuz2o6fbGbSJ5Gvm3Zuj/sKdwDOwEpbVMgt1Gi31zo dqM1hKI7c2TDrDjzHPqEk4EDFnxGz2Xuz7XYjeg4Y0MoLrImn5kRRjJTZLD6il1eKV/p nxXw== X-Gm-Message-State: AMCzsaUndXRDOl93JCZxJ0Nnmd7XfbUusROo9R1Ob1YnMRkUE52/ju6j VFNagst0UvIktkD9ovXv84a97A== X-Google-Smtp-Source: ABhQp+RxR23Uchv3/7x9v7yj6V5tlmfgNjACTmSN6H/nMM6RJbSZb/DKulUrNfLsO5q+gQVJTJTdPw== X-Received: by 10.237.42.230 with SMTP id t93mr17709929qtd.317.1508711501122; Sun, 22 Oct 2017 15:31:41 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-230-154.bltmmd.fios.verizon.net. [100.16.230.154]) by smtp.gmail.com with ESMTPSA id k79sm3809705qke.28.2017.10.22.15.31.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 22 Oct 2017 15:31:40 -0700 (PDT) Date: Sun, 22 Oct 2017 18:31:33 -0400 From: Shawn Webb To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Trust system write-up Message-ID: <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zanh2tn2izgbdqkn" Content-Disposition: inline In-Reply-To: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20170912 (1.9.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: Sun, 22 Oct 2017 22:31:42 -0000 --zanh2tn2izgbdqkn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 22, 2017 at 10:14:40PM +0000, Eric McCorkle wrote: > Hello everyone, >=20 > The following is a write-up of my current design for a public-key trust > system: >=20 > https://www.metricspace.net/files/freebsd_trust.pdf >=20 > Some of you are certainly familiar with some or all of this; > I've discussed parts of it before on -hackers and -security, and I > discussed it in greater detail in BoF sessions at vBSDCon. It seems > things are heating up in this direction, so I'd like to get this out > there and get discussion and feedback. >=20 > I plan on undertaking work on this in the very near future, especially > since the commit-train for GELI EFI is ready to arrive in HEAD. >=20 > A bit about the format: this is sort of the "meat" of what I hope will > be a paper some day, but it's still an initial draft. Moreover, it > talks about things I'm planning as if they exist, mainly because I don't > want to have to go back and rewrite everything in the future. In > reality, most of what I talk about is just a proposal at this point, > with a few bits being implemented as a PoC here and there. >=20 > Please read and consider the designs I've proposed. I welcome any > feedback and suggestions. I'll give it a week minimum from today before > I resume any work on this stuff. Hey Eric, Thank you so much for working on this. I do have a few questions. I'm curious about the rational behind not requiring expiration of trusted root key material. Can jails contain a different trust chain than the host? Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --zanh2tn2izgbdqkn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlntHEIACgkQaoRlj1JF bu585g//SLA5OM7zRX/0SziOYf5ref5HARdM9T0BjmEejcLGA9ZgcwH3i0krPJXY IznjVMVlIpXcqUA5CYrNjSaaxs1h2TIS/wxVrhPrtpM8NOezZNxOT0fm8IaG624h V1E0YO+TYn2Iy3yBrzAJI+kFnJ998cvTauapAWxtvpo3AJUfDI/Lx02yEbq21U+J JJV5vvYE029on0irPWepCJdRz9hiwUCI/f9t3yXlJLae01RgJObwpU+SXgtGOx43 e/HO/za/EEgDmB7njSUyw0sw4QWm7F1VXhemClP9jq7C+yedIkExJFfE6VynRDta crR9StOctmkdnf4M/48NGmGUndRBLDrwf0b6+gmSuZTrzP4WOkYMK5bJYJPA2xx5 DbRCOpqIc+Jvr+Qfnr2mXnUKmjM+WWo/FCx/pc7eFMaNyFQpSBpBptO/syuOTvJU MAmCBdreT56Tz1uce7JH6Q3sOQ3C3HLFn4kB1F5l4kTskiZSMOykFEUmgEfz75kF gnXCT/dJVfsYQCbGeQlU2+wCK1tt03p+4pcSyCK7cMdSd7RCjrt7H2G44UGet+lH fH3Q0FuCxfD8TuLaG5az8NpdrAB24cPPM8wghyunqDllNqb19731d6fK4+EJBmbF OOniNXf0EA3CalTN1dtRluABHZyxWidZKudUot77xJ1jqlPLDKM= =vbis -----END PGP SIGNATURE----- --zanh2tn2izgbdqkn-- From owner-freebsd-arch@freebsd.org Sun Oct 22 23:18:42 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 1EB93E396AE for ; Sun, 22 Oct 2017 23:18:42 +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 EEFC97D790 for ; Sun, 22 Oct 2017 23:18: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 33E472D29 for ; Sun, 22 Oct 2017 23:18:40 +0000 (UTC) Subject: Re: Trust system write-up To: freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> From: Eric McCorkle Message-ID: <97243355-2635-4450-13d4-8037a191d968@metricspace.net> Date: Sun, 22 Oct 2017 19:18:39 -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: <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> Content-Type: text/plain; charset=windows-1252 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, 22 Oct 2017 23:18:42 -0000 On 10/22/2017 18:31, Shawn Webb wrote: > Hey Eric, > > Thank you so much for working on this. I do have a few questions. > > I'm curious about the rational behind not requiring expiration of > trusted root key material. > So, I'd say consider most of this written in pencil at this point (minus the signed ELF extension; I think that's a particularly good point in design space). My thinking on root keys is that there really ought to only be one for a given system, but I'm not so convinced of that that I'd bake it into the spec. Certainly, though, you need at least one good root key to stay operational. If you have expiring root keys, you get into all sorts of nasty cases where your last root key expires, forcing the system down, or a system can't be booted because its root keys all expired. And expiring root keys + can't add more root keys means every system effectively has a countdown to running out of root keys. I didn't mention it, but I could see provisions for adding/revoking root keys that hook into some sort of deeper hardware mechanism, say TPMs. I think that's out-of-scope for now, but it's worth thinking about. Perhaps expiring root keys could be added along with a mechanism like this. > Can jails contain a different trust chain than the host? I hadn't really folded jails into this yet, but I'd say that's a definite requirement. It kind of kills the whole virtualization capability of jails if you can't do that. I'd say you'd probably want jails to have the option to inherit their parent's trust DB, as well as establish their own root keys. From owner-freebsd-arch@freebsd.org Sun Oct 22 23:21: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 010C3E3979C; Sun, 22 Oct 2017 23:21:11 +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 CE34D7D9D7; Sun, 22 Oct 2017 23:21: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 9DA2D2D2D; Sun, 22 Oct 2017 23:21:09 +0000 (UTC) Subject: Re: Trust system write-up To: Shawn Webb Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> From: Eric McCorkle Message-ID: <96ff2a56-5089-eb4e-cf57-6c6d2cb4667e@metricspace.net> Date: Sun, 22 Oct 2017 19:21:09 -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: <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> Content-Type: text/plain; charset=windows-1252 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, 22 Oct 2017 23:21:11 -0000 Accidentally replied to -arch only, re-replying to all lists On 10/22/2017 18:31, Shawn Webb wrote: > I'm curious about the rational behind not requiring expiration of > trusted root key material. > So, I'd say consider most of this written in pencil at this point (minus the signed ELF extension; I think that's a particularly good point in design space). My thinking on root keys is that there really ought to only be one for a given system, but I'm not so convinced of that that I'd bake it into the spec. Certainly, though, you need at least one good root key to stay operational. If you have expiring root keys, you get into all sorts of nasty cases where your last root key expires, forcing the system down, or a system can't be booted because its root keys all expired. And expiring root keys + can't add more root keys means every system effectively has a countdown to running out of root keys. I didn't mention it, but I could see provisions for adding/revoking root keys that hook into some sort of deeper hardware mechanism, say TPMs. I think that's out-of-scope for now, but it's worth thinking about. Perhaps expiring root keys could be added along with a mechanism like this. > Can jails contain a different trust chain than the host? I hadn't really folded jails into this yet, but I'd say that's a definite requirement. It kind of kills the whole virtualization capability of jails if you can't do that. I'd say you'd probably want jails to have the option to inherit their parent's trust DB, as well as establish their own root keys. From owner-freebsd-arch@freebsd.org Mon Oct 23 05:47: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 01694E411DA; Mon, 23 Oct 2017 05:47:06 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 C823E3574; Mon, 23 Oct 2017 05:47:05 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x232.google.com with SMTP id a192so10918685pge.9; Sun, 22 Oct 2017 22:47:05 -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=0q5lz4vgOOvYOzOPoUa6ZR0eXqAqv1sEg7B+TV1HUuE=; b=Q26oBTmRY5s9zz4ablTkUKhvf39DyNolacyyqaFb8KcFQBePu645ObX2WVyF/GDGgX hooDNDCVjomnvmHoUbt7d7Xe0C3o6UzUK+hUax2P6QJTcX96gAz026LSYHDRwCc46JGn CcysUzUJdY17zzSSLl2xHrgMYd1cnQ8rfxq2I7nZS3dvyRMAE4DqZBEdPkYlkdrC3VKC J6VROi8MLBicJwLHxh8sULgBYFYbE+H9mhpCBQHqO0s+rNTq0L7GMbEbwfod2iy/JI/e paj2zze/pOKVKNcUeSAMwQEcbpGJnHUE9T7Ag612qWn6ZQTkYb/3hVh49c0LSx9ncs1Q SVlQ== 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=0q5lz4vgOOvYOzOPoUa6ZR0eXqAqv1sEg7B+TV1HUuE=; b=PAY9UgAMUYlYoHJCXqzKa/1FTW0g1Nv9noK0yeByMpXPfYsQFPtF0RPhjwe/dg4wUT +oggHrzIyMR7UEn3LorSpEhPdyRlOXNRDCioD/4J1GaAwHYka0uBEf/oBhwkroH6cTSM DBefw8fNoeMOlQXSXbPz9aBhR686zmj575WS6qWqsWGiCQRXKoUyfRUTUh9NYuA/SWFm zS5ygBAbtB5dmZDai0kv8beg3+6hEf7hXCol3paqOvLMr11G00BkeI9AQLe94DNJGNRK G4LG7Z42TGoEGoTWbBextW+SDcoQ5sQ/WG0Bnz7nZ6GHJRl0Sepd6l/ldblztnecsfV+ AZXQ== X-Gm-Message-State: AMCzsaWQ+cGWBjiTVkUcsLE8KeBGOoilaPqa9USauEPROUWn3lhqQeMS 6cQC08uXXIKb1QfEG2Ql7w+UIHx+ X-Google-Smtp-Source: ABhQp+TPlYDcyOlsUs34GSrw1abLBNp0hWu9e9BRO/CwdbFETJDDs/yhgqSb27OqTlNRZ2vzQyqffA== X-Received: by 10.99.51.72 with SMTP id z69mr11083341pgz.317.1508737624995; Sun, 22 Oct 2017 22:47:04 -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 68sm11024471pfx.105.2017.10.22.22.47.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Oct 2017 22:47:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288"; 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: <20171010211428.GA51868@alchemy.franken.de> Date: Sun, 22 Oct 2017 22:47:03 -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> 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, 23 Oct 2017 05:47:06 -0000 --Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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. An idea occurred to me (after having dealt with building things over, = and over, and over, this weekend): since we can=E2=80=99t rely on the = ABI on ^/head to be stable, why don=E2=80=99t we produce working = dynamic/static toolchains on HEAD-1 in ports, then require them for the = areas that can=E2=80=99t bootstrap (yet, or at all?) with clang? We=E2=80=99= ve already done that with some of our code that=E2=80=99s been deorbited = from base (like rsh, etc). I don=E2=80=99t 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. Thanks, -Ngie --Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288 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----- iQIzBAEBCgAdFiEE5bk3FaGcY5rvqmb79YOpJmkwhhUFAlntglcACgkQ9YOpJmkw hhU1YA/9GqhSESf6+PxdqZzHes+zqITzwrGXIMZjdrOrE8N9lRSDVZtFGPva0jWl xuzpUEdHrFtnY7+ByCaA5qgy4yqLck1X82E2IPdUjeGHSzo+b0skonHbYvGPkT/n ow2PkuuLo1XkbiFOpRkSb3MZ3yqut7wIF7WkL5COn0nkyjLsswsfdHnVwNB2Txq4 4cYjzO7RYcjCI6zKZVg38OoV9sKaAG/2/DzJNPW1KIaZjdzmD7AXn+2+Fp3KqmAT vmNNydbPr43tTPQ8AHBRLgVEC4qz9vmXmLArqC86VKWo/S6kewzFtAHL3SH0KYjX bNsNvPV1XyWl7HnVT/0fWmpjv42rnVvd98jmW2GWO+1HxQTQB3BNJlaEHzJTVsGn CkxarkL7hARHnXJ8bzE4Ecn7gLdn3e+KjLm2cesrTJnqdr2iEHrUP50BjrR9bXFN XtFPIGc7sP086PWyeTnx1AGu8BDIsSlmYXJpo28PNqM6HAxjBwW0LL2isAL79YEt Gvitp/IYUKulajlAlycyXFGtBHPTdP6WGaPwgVl1GFDWq7bq8BDUfpc171KaDpfs sY/uSG8ooC/R32mRBXMY2XtywWl6exzYyM/5SEK0cEcyD9qFncbALurJ9/D0X6+Q SJIHRRum1rCp78VGNReKKQJrQeeAc18uUBm5MQQFlA7bYCBN0hg= =Tnci -----END PGP SIGNATURE----- --Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288-- From owner-freebsd-arch@freebsd.org Mon Oct 23 05:48:31 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 1CE89E413C0; Mon, 23 Oct 2017 05:48:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 D8ECA3698; Mon, 23 Oct 2017 05:48:30 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x22b.google.com with SMTP id b6so16295183pfh.7; Sun, 22 Oct 2017 22:48:30 -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=LdiEHQ2mv0kUl9PlBlajQk0kiNfZ7wDP4lX5NWuIQw4=; b=CncEuMeYDTII4PabpgdYEGLOGq/rWYFlIPpTSgeZSEBV8SusQqUP6MXhpm8cmi4XDE 9x061taraxEeuUJ8KuTJ3qrgev7d7r9famcmdpI0McGuubo+I8MdEeP4zw/9xUR94T/v 6jrri6SYpolRUsgsWzNv1tfLOas4lcCLwh+xW8p7nu95z5xI/FnAjPkS8AsDq+p9q8Pz 8dndAoXQy57xewTyhjJ73ZUBbe87RQyyiKqQst3HqtRXGWxnnttTeO03B4jbMtZnTO+H IgWBQptyrjll0q6ebB5npJH6ZtabOZ6/PUyTWuloQnvr0M0o7FVr+YuQk24oom1AyiSY fs3w== 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=LdiEHQ2mv0kUl9PlBlajQk0kiNfZ7wDP4lX5NWuIQw4=; b=amhAH2G+eLbJej3UiL75HuKbqQdu7058G0IsoZ7dpjPFWyOrqdhvQdYqwmh8HFL0za bh4a4radq3dK2aejHPmpmozJa/hlYR/4bdwklRezySJINNLEerhRnSY0LuA7FtK0yCko siZ5rpkI5BApRiVHdqj1OrsOw16+ujw5sTvxQPr59cvMX51IG5WW4dMK2lGVjAL57/ZR 9nPZEGLO2fO+LNxiyICaFdYJAy9FYAVc2jaPQOHCE2BPQyMApR98d84AygzCICj2z0Lw XsHBMUpwiO//DS/+jRQbABUajMNHr3uUbtLs09sn1wZoqWwQh3fUNfC8qvTwQq7z7ApQ 2dJA== X-Gm-Message-State: AMCzsaXyuWN/1Eupu1g+Ptezy0+sQ99WCVysHUGFLCBO35GY1CW8cZZQ hAYfzc+vgaXQQVopDDq+MItHjTon X-Google-Smtp-Source: ABhQp+QKfhJ70djMS65Zg1DZYP/z/Kxx22WyDUEGyelMSVzU66nvUXvLKaY+/H1Oja0PKFQmRBTGrQ== X-Received: by 10.99.109.75 with SMTP id i72mr10904352pgc.268.1508737710156; Sun, 22 Oct 2017 22:48:30 -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 d12sm11238400pfl.140.2017.10.22.22.48.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Oct 2017 22:48:29 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4"; 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: Date: Sun, 22 Oct 2017 22:48:28 -0700 Cc: Mark Linimon , "A. Wilcox" , Gerald Pfeifer , freebsd-sparc64@FreeBSD.org, freebsd-arch@freebsd.org Message-Id: <353165E9-561A-4A4E-9906-3471928C770B@gmail.com> References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@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, 23 Oct 2017 05:48:31 -0000 --Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 22, 2017, at 22:47, Ngie Cooper (yaneurabeya) = wrote: >=20 >=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=E2=80=99t rely on the = ABI on ^/head to be stable, why don=E2=80=99t we produce working = dynamic/static toolchains on HEAD-1 in ports, then require them for the = areas that can=E2=80=99t bootstrap (yet, or at all?) with clang? We=E2=80=99= ve already done that with some of our code that=E2=80=99s been deorbited = from base (like rsh, etc). I don=E2=80=99t 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. =E2=80=A6 and yes, this can be interpreted as =E2=80=9CI will do it as = long as people don=E2=80=99t bikeshed me to death on the idea=E2=80=9D. -Ngie --Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4 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----- iQIzBAEBCgAdFiEE5bk3FaGcY5rvqmb79YOpJmkwhhUFAlntgqwACgkQ9YOpJmkw hhXJqg/8D0o4xyRPGevVzoN9XsJGlfC9ZBOrfOx6F9Q2N8yGWyn8IH/git4wHFej xw0sshT5ySbmVa0dHqikArzE4pCzAXfGMa3UoZFUT075FZJHOeYqsQsVnKOCWbEo Zj4xW0z2UGxBKG0CnfxoRpIgh3W4Ch8uxE2ZyFmYvuzTa6EQvmHxN0Kh6kPv+6D7 fcS/oVKie8fIjdga5jl/jaRWandq6Nefweo1BZ6yS/0P+KGdL7QU/Vtgat59ILlb rkYYcigagxLHJCY3NraBb/bFwvIwMTjfX5iloIOccjXzKxyZCfWi4aLL+cMvEaIO 6KXsKlRxPnFCqj6edlf5A7lr/Hz8E3+luH2U72FmBgYLf4HD/cXrxelHsxJiSP4R HLXQrI7zuNJCGgUwIbIS9ThGejq/oYGDtao403KPSfiO7z0/k0zY5wvtKtwW8jIi 9GQANY10H5+yFwIUpdRCaPEYKCVjTp1nISrW0w2ZBrQY4lXsvuZ9Ll6kRjB8LsI1 S4EJDjOlFNdoDYwvwnJGShl69pzjAffO8kStInJATP/d4Qz34R5oJubo+LzKRjAG TFcWJrPiQwtfzDpricjWK0i1mdqGOc6JlJ4o/9yjUSywPeqn8zaQn/7/n7123ieH 5xTGcBbxpwJhvVqv9mV02zd9znhDrDNmWj3vgcFTvx1kniy3X5Y= =MoDd -----END PGP SIGNATURE----- --Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4-- From owner-freebsd-arch@freebsd.org Mon Oct 23 07:11: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 CDA9CE42CB3; Mon, 23 Oct 2017 07:11:27 +0000 (UTC) (envelope-from romain@blogreen.org) Received: from marvin.blogreen.org (blogreen.org [151.127.25.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5F864CBC; Mon, 23 Oct 2017 07:11:26 +0000 (UTC) (envelope-from romain@blogreen.org) Received: by marvin.blogreen.org (Postfix, from userid 1001) id 7A2A2A6DAD; Mon, 23 Oct 2017 09:11:20 +0200 (CEST) Date: Mon, 23 Oct 2017 09:11:20 +0200 From: Romain =?iso-8859-1?Q?Tarti=E8re?= To: freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org Subject: Re: Trust system write-up Message-ID: <20171023071120.GA72383@blogreen.org> Mail-Followup-To: freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> X-PGP-Key: http://romain.blogreen.org/pubkey.asc User-Agent: Mutt/1.9.1 (2017-09-22) 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, 23 Oct 2017 07:11:27 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Eric, On Sun, Oct 22, 2017 at 06:14:40PM -0400, Eric McCorkle wrote: > The following is a write-up of my current design for a public-key trust > system: >=20 > https://www.metricspace.net/files/freebsd_trust.pdf Two minor things while reading: 1. p2: from a end-user perspective, `trustctl` expects DER encoded certificates and CRL; while `certs` and `rootcerts` outputs PEM encoded certificates=E2=80=A6 So the formats are not the same, and may= be consistency would be advisable here; 2. p3: 'the preferred configuration' is said to be the most used one, but as described it only includes a single crt+key and does not look suitable for distributing upgrades with freebsd-update(8). Unless I missed something, I guess it's just the way it is described that needs disambiguation: - "local nodes" are basically what is described as "Preferred configuration", and have a single key+crt. So these nodes can only run the code they signed. - "high-security institutions" are kept as it, that is a single crt; So these nodes can only run code signed by the institution. Hybrid systems can be built by having more than one root node: - "preferred configuration" have a local key+crt (as an local node) AND the FreeBSD's project crt. So these nodes can run FreeBSD's code and their own code. - "standard FreeBSD images" as described have the FreeBSD's project crt. When installing, they generates a local key+crt and add them with the FreeBSD crt to the new system's trust store. So these images have the "high-security institutions" scheme, and install systems in the "preferred configuration" scheme. Thanks! Romain --=20 Romain Tarti=C3=A8re http://people.FreeBSD.org/~romai= n/ pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) (plain text =3Dnon-HTML=3D PGP/GPG encrypted/signed e-mail much appreciated) --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEgjSaeOfAuAcLWYD/uk0dlVESM28FAlntlhUACgkQuk0dlVES M28IUAwAkC1TcnDuhF67t+1RbvZL5oTxtDBQjzzOTiIhX+W/Q8oZDMPGa2xpAyPP BxPX8oCbLLsWCP/FkVmMzxHz0zNSFTMQSPCzLfkhPUZzVNlG6XcF211U97umofQf ij2pvazZXLYcaH6sFkVbpjIGqoLehCgCnU87imD/stB8v1bpmr8qTOrNG0qVH5BF pWFa1rnRCouY6YRvyNxwmzW/tNbEeFqJ07t8vDSjG48bF7jbSezM/SLzmettl9Fi EFGs1GTLtqAVLX3XomajDGd+N76xAq6WEL+g5ys2Rm31BJoj3JcfREoHzEzSGiEW LaTJllt2r5Bz3EMPKGqf6i/fd8YiyJfSn/FUrpdO4iWHnYPEqBCVQ74ran/l3trX OYlFTyjwbG0/ocTxO1ZQ3wmdQ06dor41PiL6Rylis2ZZNxXI0IzjjK667Bs0LxHm +cBsCGDnmgcAhRPy7pgeXpfEd/w3VZY3mIB3kGYpYXQ8a5aJiqv7Pq5JEt/xndqM rPX0N+/z =ihHe -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-arch@freebsd.org Mon Oct 23 11:56: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 A1B2FE49424; Mon, 23 Oct 2017 11:56:35 +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 701E66D98F; Mon, 23 Oct 2017 11:56:35 +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 A2E352E4F; Mon, 23 Oct 2017 11:56:33 +0000 (UTC) Subject: Re: Trust system write-up To: freebsd-arch@freebsd.org, freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> From: Eric McCorkle Message-ID: Date: Mon, 23 Oct 2017 07:56:33 -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: <20171023071120.GA72383@blogreen.org> Content-Type: text/plain; charset=utf-8 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, 23 Oct 2017 11:56:35 -0000 On 10/23/2017 03:11, Romain Tartière wrote: > Hello Eric, > > On Sun, Oct 22, 2017 at 06:14:40PM -0400, Eric McCorkle wrote: >> The following is a write-up of my current design for a public-key trust >> system: >> >> https://www.metricspace.net/files/freebsd_trust.pdf > > Two minor things while reading: > 1. p2: from a end-user perspective, `trustctl` expects DER encoded > certificates and CRL; while `certs` and `rootcerts` outputs PEM > encoded certificates… So the formats are not the same, and maybe > consistency would be advisable here; There's a reason for that. The binary DER encoding is very easy to parse, and is far less likely to end up with vulnerabilities. Prior to learning about the discussion surrounding BearSSL, I had been working on a minimal PKI implementation which only parsed binary DER because it confers a number of advantages. Each element has a length, so it's easy to detect malicious or bad data and avoid overruns. Also, you can easily skip over data you don't need (such as the complex distinguished name structures), and since it's a distinguished encoding, you can treat any element as an opaque byte pointer for comparison purposes. All this closes off a number of attack vectors. PEM encoding is what applications use, and it's much easier to generate than to parse. Generating it is straightforward if you have the DER-encoded data lying around, whereas parsing introduces a number of possible errors. > 2. p3: 'the preferred configuration' is said to be the most used one, > but as described it only includes a single crt+key and does not look > suitable for distributing upgrades with freebsd-update(8). > Unless I missed something, I guess it's just the way it is described > that needs disambiguation: The idea is that you'd sign FreeBSD's vendor certificate with the local system key and add this to your intermediate certificates that get loaded at boot time. The installer would probably generate a local keypair, install it as a root trust certificate, then sign the FreeBSD vendor certificate and install it as an intermediate trust certificate. This would be enough to get an initial system up and running. Users that don't want to trust the FreeBSD cert could then do a buildworld and delete the signed FreeBSD cert from the intermediate certificate store. > Hybrid systems can be built by having more than one root node: > - "preferred configuration" have a local key+crt (as an local node) > AND the FreeBSD's project crt. > So these nodes can run FreeBSD's code and their own code. > - "standard FreeBSD images" as described have the FreeBSD's project > crt. When installing, they generates a local key+crt and add them > with the FreeBSD crt to the new system's trust store. So these > images have the "high-security institutions" scheme, and install > systems in the "preferred configuration" scheme. That is also an option; however, I prefer the configuration where only the local system key is a root and everything else is an intermediate, as each root key represents a source of trust that is hard to revoke (you have to power-cycle). It's almost always better to have a single root, and make everything else an intermediate, though I'm not sure enough of that to bake it into the specification. From owner-freebsd-arch@freebsd.org Mon Oct 23 15:56:03 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 D2105E4E874; Mon, 23 Oct 2017 15:56:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B45D874E50; Mon, 23 Oct 2017 15:56:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9NFtsAc028830 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Oct 2017 08:55:55 -0700 Subject: Re: future of sparc64 To: "Ngie Cooper (yaneurabeya)" , Marius Strobl Cc: Mark Linimon , "A. Wilcox" , Gerald Pfeifer , freebsd-sparc64@freebsd.org, freebsd-arch@freebsd.org References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@alchemy.franken.de> <353165E9-561A-4A4E-9906-3471928C770B@gmail.com> From: Nathan Whitehorn Message-ID: Date: Mon, 23 Oct 2017 08:55:54 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <353165E9-561A-4A4E-9906-3471928C770B@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVYAHeJ/P6fIQ1B9P93khEvMd85+BIdkyZjUyOFl0VHV2qP1EcwVLTJ1ebqyPQtXqZ0BzTgG8n4l1unXnx9d5pCIY1TMkwCtsHM= X-Sonic-ID: C;NgEMpwq45xGvWYlQ3iMJ6w== M;OlBFpwq45xGvWYlQ3iMJ6w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 23 Oct 2017 15:56:03 -0000 On 10/22/17 22:48, Ngie Cooper (yaneurabeya) wrote: >> On Oct 22, 2017, at 22:47, Ngie Cooper (yaneurabeya) wrote: >> >> >>> On Oct 10, 2017, at 14:14, Marius Strobl wrote: >>> >>> On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote: >>>> 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. >>> 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. >> 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. > … and yes, this can be interpreted as “I will do it as long as people don’t bikeshed me to death on the idea”. > -Ngie > I'm not quite sure what is being suggested, but the core problem with this particular thing is that you can't build ports without a toolchain, so there's a catch-22. The only way to break that involves packages -- which we don't tend to provide on the architectures that have the problem! bapt has done some work on getting this to happen (the base/ ports), but the base/gcc port is both out-of-date and doesn't seem to build anymore, which is where I am currently stuck. Any help with that would be really appreciated... -Nathan From owner-freebsd-arch@freebsd.org Mon Oct 23 16:14:59 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 5FFBBE4F226 for ; Mon, 23 Oct 2017 16:14:59 +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 F1BA375C7C for ; Mon, 23 Oct 2017 16:14:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 4b3e415d-b80d-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 4b3e415d-b80d-11e7-a893-25625093991c; Mon, 23 Oct 2017 16:14:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9NGEjrb001381; Mon, 23 Oct 2017 10:14:45 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508775285.34364.2.camel@freebsd.org> Subject: Re: Trust system write-up From: Ian Lepore To: Eric McCorkle , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org Date: Mon, 23 Oct 2017 10:14:45 -0600 In-Reply-To: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.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: 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, 23 Oct 2017 16:14:59 -0000 On Sun, 2017-10-22 at 18:14 -0400, Eric McCorkle wrote: > Hello everyone, > > The following is a write-up of my current design for a public-key trust > system: > > https://www.metricspace.net/files/freebsd_trust.pdf > > Some of you are certainly familiar with some or all of this; > I've discussed parts of it before on -hackers and -security, and I > discussed it in greater detail in BoF sessions at vBSDCon.It seems > things are heating up in this direction, so I'd like to get this out > there and get discussion and feedback. > > I plan on undertaking work on this in the very near future, especially > since the commit-train for GELI EFI is ready to arrive in HEAD. > > A bit about the format: this is sort of the "meat" of what I hope will > be a paper some day, but it's still an initial draft.Moreover, it > talks about things I'm planning as if they exist, mainly because I don't > want to have to go back and rewrite everything in the future.In > reality, most of what I talk about is just a proposal at this point, > with a few bits being implemented as a PoC here and there. > > Please read and consider the designs I've proposed.I welcome any > feedback and suggestions.I'll give it a week minimum from today before > I resume any work on this stuff. > > > Note: Apologies for the external link; I had originally included this as > an attachment, but it was too large. > _______________________________________________ Any thoughts on how to validate executables which are not elf binaries, such as shell scripts, python programs, etc? -- Ian From owner-freebsd-arch@freebsd.org Mon Oct 23 16:44:44 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 C2BF7E4FB48; Mon, 23 Oct 2017 16:44:44 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0115.outbound.protection.outlook.com [104.47.36.115]) (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 5A23276DE8; Mon, 23 Oct 2017 16:44:43 +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=yMde/2kKxMrODPN/KYl1VtOtyrUSnW7Dzu4Nz07SchI=; b=XArATkeXvmDqbQv/+8lqV0OAlyCJBMhl1ooCRPCYzjAXkajGiDk0CWRtQAp4twqas8erprSx1j2iJZBHqfkKTqvjYIt/enYm0SEtCpCE5h3KkeyKbC2yMlmcFer/+HXoUl1Rkjl92Qghwax7c+N8p85ud7Kd+Vz2s5tuQoW7nGc= Received: from DM5PR05CA0010.namprd05.prod.outlook.com (10.173.226.20) by BY2PR0501MB2070.namprd05.prod.outlook.com (10.163.197.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 16:44:42 +0000 Received: from DM3NAM05FT035.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::204) by DM5PR05CA0010.outlook.office365.com (2603:10b6:3:d4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 16:44:42 +0000 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 DM3NAM05FT035.mail.protection.outlook.com (10.152.98.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 16:44:41 +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; Mon, 23 Oct 2017 09:44:34 -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 v9NGiXmw010661; Mon, 23 Oct 2017 09:44:34 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 6302B385567; Mon, 23 Oct 2017 09:44:34 -0700 (PDT) To: Eric McCorkle CC: , "freebsd-hackers@freebsd.org" , Subject: Re: Trust system write-up In-Reply-To: References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> Comments: In-reply-to: Eric McCorkle message dated "Mon, 23 Oct 2017 07:56:33 -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: <67124.1508777074.1@kaos.jnpr.net> Date: Mon, 23 Oct 2017 09:44:34 -0700 Message-ID: <67125.1508777074@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)(39860400002)(2980300002)(189002)(199003)(24454002)(81156014)(81166006)(16586007)(55016002)(316002)(229853002)(9686003)(68736007)(8936002)(76176999)(54906003)(305945005)(478600001)(106466001)(97756001)(77096006)(105596002)(8676002)(86362001)(356003)(46406003)(53936002)(4326008)(189998001)(5890100001)(69596002)(23726003)(76506005)(117636001)(47776003)(50226002)(6246003)(7696004)(6266002)(53416004)(97736004)(2810700001)(7126002)(50986999)(97876018)(50466002)(6916009)(107886003)(2906002)(5660300001)(2950100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2070; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT035; 1:2iRSCjxPQjeczHQT2ucvAqOHva/Yprb/WaCmqZWnYTMc9sLV9qRxVVpWQq9XJO2hYBYmlBVhG45k/hTlnPVR96LrlcPfa8XDtMdl1o9xjh3BCiW8cnj6sS6NkApUdBlG X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5807dd2c-0f3d-4b38-9dd3-08d51a355be6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:BY2PR0501MB2070; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2070; 3:woq6UcgmC6fyVTTCEIUZ9/rELmslIJVnaRcUb/gvVop9EzBBOEeGrpREaSLDbHl77sgZJfi673tCJsSEaUUDq/DMqKHIjZOXeK+nUp22ew+WmdXDsj7vb9pI27WtYscmFgSV5oOyuJUWyGtVjWMmchFz2CWZmPkRTwqWn1D5IRJAxDCWRo4F9hf1cUbVMympaYMMuLwPFJgjE4qVPWHCyYnhe+M3fDNMEFWQ27nQetHheuOptL3EjHxbjQ8YsBjAKaI3IovC2mTOUpd84f9HiJkhfPvJCYUcnPgKb5GM9YRijk+0S0nhEhFLhXjyI0f+6SZKDotTwZApfF9TFo3t/+VItP//yNsb241GJJHw54U=; 25:FVPBOKX7nTAC+zzX9eHPk6snClOGLjnl9IiKpsAfwmXezR1AxC+5/NHbIVP9uQrsj4sNt95UPIzZlgX7OFwL7rvR1Ramq9brWIiZ/5JEguje/yJtMd6YishuA/+S8CT42oqTULd79D3FmwpU/9Mop3V8TR5VbJ1nWowGAoVfiqhkhJf+f1gkD8J/A0irgzc54RcPoS9lStj9Oh/42MBLMNNfUq1UG0JewnNlaWudATs816nCe0tiQxmiPQdOvYo1ph/sedtOL3QnwR8Nd9bLsOxp8of0QK3v4lw2dWgyDw+7QgNAlgqiYg3vOW6oz653tA8IH9mwr3mwcK32+e6Y0A== X-MS-TrafficTypeDiagnostic: BY2PR0501MB2070: X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2070; 31:P6lSPaSXcWBJ4z1J5ykj37uAHobclxUyq4+F3jhNTv4oWQVMMyPwUJaaW2Otm2iIwz9e29q+nCSNMNbZSlEs6/1YaDI+R62pS6Q3Q93C4XsogWM2gM5TgHYTF5omF14+WGMOt/WH6O/ZwL+BMkVWb0wrtnRkVUu1hxENA0SkNRXN2rXhh5meydMl29ixTZXRloltWk//aVA1CejaX2+Y/hCLGBhomM7lW9ovDhoEYew=; 20:5tjKzPZaPyVonTB/6AQC3Pb5c/2tkB4V/l51CL6s/BGUUQPZV3O2OF1tbsgJoEtkHGbTj0Z6XbCxTjZHwhr6mk6H3oEvhEgzbEXZeW0m7zA33gJ7/WRbV5u5DqxkcjfzJekNCR0aKVIodovqT1MOLLKr853NMqGZmKcbHaQpyVdA1fZbeaaJ0uoKojdiZL/ejTnIVZPd3rMZ2z9JCtDuje2klZzrgR9RUuPOY9PCDZSav8GO86YSDhB+RDtjR6WcIUyl84haHD9cwd4FbaX9Gj7RzMfsydI5auaox5j0G1tlrr7XVQKhrtOnF2PZ1M3Yh6TYfMXYvFRGaQjUkaMxSsEzUXLxKW/w1D7yL/ITgjffOFAm4wQtUwGyxoo0Qk87Ke7UjukhTlOnqfCzZWb8ULqIPHJ7xaVJZ0DJwkMmliri5XlAZD43I5mvhDqY+wsxG8aooZHZF5S+OAFnuP/NGiHxjh+pYw8NEmK4fwurcSQU95NbdnMAz0Vt58+nnOPo 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)(5005006)(8121501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR0501MB2070; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR0501MB2070; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2070; 4:z/giGsvgobfxUErTwig0r/dstWtq43Q44ddWpdNAmF6Kb0wHLkzAT8jBN/ljy7zUoWvdXOWUbkCeZ51ui4TYP6uCPvpq6ZLBQOXe9SH9/n3CNCujsJN4n8gooXKJ3OF2la2LF4kDqguf2ms4DhWijkwtsYGMhPKZZFiRde8dPTxnqqtOosqxgyjM4zD4t2F5b32TVMQGZ5I9p13KGXmvAYsmiUM1A/1VyPrWr6jfLRwuZWW7VURjykLrBx1zKVMqCLMoaeoeD095MEBMmsr9/w== X-Forefront-PRVS: 046985391D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0501MB2070; 23:tvkNoxYOcb2BtQGCASrI0zNkdAOprOys1fqQ34J?= =?us-ascii?Q?WIu7CqnFlkk+yeis/Q3Zt7SZhwgUZVnPoLcBjRJEpxq3RjN1mkxlqC0fqCFm?= =?us-ascii?Q?7OlzAyDtyUaZyeIufqv+0DzuZ60f36MfvKpK+9Dbeg2g0LXMNe4ggEclcQ2v?= =?us-ascii?Q?YiKaMljOLTLOrhBNNvbHfUCLu8elPpwCu/mayOoNgeqnhC+/C21pHXpq5emI?= =?us-ascii?Q?FzXqjjaWSD9NWc1xT82wcsfv0W7+wcEFoeks/OWMVJBAb0qxjBtYrvrL4ba4?= =?us-ascii?Q?xqHXsTQCqhsGPoH7cHo/A8pArM1SQYUgqswbim+1kl3a5wjM6a2tLAmR2zii?= =?us-ascii?Q?Vfm6IGQluw9b/NALryezr1Az5VQfStCp7IzvgvhbR9g7NPWHGYF/fl/PbQm5?= =?us-ascii?Q?8dUTJx23C3Hsu0jhMFNGDAmR1nW2NFbTlcoK62xE9NPF3BAt5shufCfH51Jt?= =?us-ascii?Q?ywUkPvnFMTwmlAJLunm+cxru1bGn+hAmJL+LmgcRhdePXHta+0ULnxGzXyZz?= =?us-ascii?Q?LVE/cBT8svuMv8wlKfGkf+NPOBbbPUdCWB99Xb1qogtplfOsonscXmwmfLyQ?= =?us-ascii?Q?NuJoS3E52k4T9qZ4SzWiHWp9+T9ym4SIH4R+tHyjAQwDkbrOtozBVSjGYAmw?= =?us-ascii?Q?Mp5Q7aNhOY2dPE7MLLJruWN3QJHUW+KyitLwzi0TNvVZkH4UU2pUGW7ZKjY4?= =?us-ascii?Q?gX6ipXrujNGd74WMNjIQX/UTt9TSq/fC2ixnZYoJqnH85gseoTMNDWQ42jmH?= =?us-ascii?Q?ZAzB0u9GZKJn81E5CdVNCKkB/r63zv8drob6e52Ko5/bEmSQVlCwuvZ5Cmlj?= =?us-ascii?Q?oBdWWS6vABDMoD9sIgl/hRusIdUZzDcBCGdvIkyLoPQzyzDlPl9ie8JYr03W?= =?us-ascii?Q?U/Tv548FWT/QqV+wgDk8tK6p20BQGXNzYbznuRIhbeoDEiTtH8s/2Sy2rWof?= =?us-ascii?Q?05+u51VDPCsrCWzFR0PSUn0V2/hdmdt674bxVOZjXu+OgDbdppwT3oQeLvmE?= =?us-ascii?Q?dzoW2smjBpBYTEQdcVZZJxM45wgvmAE1WDCX31ijOzmQd6Ra3cesBgNdY0FL?= =?us-ascii?Q?rT6GhHdOKtnaw8kTv35PrslcfV4TASJZq/taEjc38o5xel+7FSiI5eF2wK41?= =?us-ascii?Q?9j4MbFj0icinmqHH8FncVtK6yePOq4YEF4D2PHWPMEXCV07zHUxcvFOF4pJQ?= =?us-ascii?Q?G2gmaAbWPq9LIRqoo4ovK7JMV6p1H8/j3gXrnLHVNblwGvvQZpaFQTT82wQZ?= =?us-ascii?Q?xw4q49uCD17S23rwkZ3OKG98bzMfvQMN2R+uMPdZ4E3DJLzxt2DHINUwf/VP?= =?us-ascii?Q?C8Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2070; 6:/a6En+FiEU8v5YF0hQdK3BLQLD/FTBOkmsYlPqMP/YwDlilpqScCysb84yZ900J0AIipA47xy+MqVUP7AxESq6NQhe7CUBRHX0XOF2unHlIqGLjCRTp9+3EkB9YjKcuk1kUoRS+3ZW0H9CsmQDZuJJUru0jX5YpPXGoAbr5hzX5M/ouqu+8gy3vB1nuaqECIESQACvwXaukcsquPQRh0tv8oDPt/8eIydBx/F4sH70Q+W2nUzdcT8Bg90ZtJrkdObxrgndQnGqaxPNRKkuhsIe/Ztag+u0nztfb+7ySn+7c8rCJRdZ7trJ+LL3RjH2Qnvq6VdHRKf3Tb6nEohEQue0CBxJ7rZHDXL1rvd3wMupw=; 5:IgAebuozMqZ1rzsCFqkGD7AocGN8942XS1DVXGr+BOT+TSVLprtBp6xZarj2Tze3e6tv/nQq3T5Y/8NHQs3+V6qwfjwgjRMbM6qaJ06aGvUtaaBfJUpKGas4pzHAkLkjpXxT9NPjdsOsB+8o6clRwD1r2yBBjcIm1coaUKKVm9g=; 24:X3pga876BuvSCEgZqETIt3sBV1rjTd08sl2vF7es6H57XJVQ5da30y3/3v0rO54RKpWtZPbSpFlSfylciX4SciMnrBN9FHO0sCHaDieVYIY=; 7:Todev4OSTdtNncpszEYJdskeCAAzZ8GyDbP8DEAM+C5QOjnJoMw+zRVHBL0hTGjLHMozvv3cdsd/bzxNAqIN+C6/JDaz7TxAeLEy2QtOpVysSHjd46c0mOz1Hj8miOH+5U6EtV7oUykJgOoOkGzieRQHcCaTetm1jOptsVu626Ad8dcKpBhVl5M9zRA32F1HHCYyqYfWjZH0gm7pfZyAu2W//Vl66gsFUvZPY8V+v9R4H4YNAaH5rW55N/ukNqIC SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2017 16:44:41.6472 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5807dd2c-0f3d-4b38-9dd3-08d51a355be6 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: BY2PR0501MB2070 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, 23 Oct 2017 16:44:44 -0000 Eric McCorkle wrote: > That is also an option; however, I prefer the configuration where only > the local system key is a root and everything else is an intermediate, > as each root key represents a source of trust that is hard to revoke > (you have to power-cycle). It's almost always better to have a single > root, and make everything else an intermediate, though I'm not sure > enough of that to bake it into the specification. While we as an embedded vendor might not necessarily want to support any local signing ability - or to be able to limit the scope of any such ability, there should be no reason you cannot allow a FreeBSD.org root cert to be honored in parallel with local root. This should allow updating system with both locally build s/w and pre-built packages from FreeBSD. FWIW when designing the trust model for Junos, preventing any local control of trust store was an explicit goal. With the advent of secure boot and TPM's, there is potentially scope to allow for mixed control. Please have a look at stevek's mac_veriexec patches in phabricator. The verified exec model easily allows for "signing" any sort of file, not just ELF binaries or needing to use special "attached" signature formats. Thus it allows adding "signing" with minimal impact to most of the system. This could probably work well in conjunction with your trust database. And of course my loader mods follow the same model, so signing loader.conf, modules etc is all simple with minimal impact to loader itself. --sjg From owner-freebsd-arch@freebsd.org Mon Oct 23 19:08: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 79A47E529CC for ; Mon, 23 Oct 2017 19:08:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) 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 550EA80605 for ; Mon, 23 Oct 2017 19:08:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 51428E529CB; Mon, 23 Oct 2017 19:08:29 +0000 (UTC) Delivered-To: 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 50E30E529CA for ; Mon, 23 Oct 2017 19:08:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 1A1D080604 for ; Mon, 23 Oct 2017 19:08:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id n195so7211007itg.2 for ; Mon, 23 Oct 2017 12:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=ItzKNeVLD5pa3Oyli4ooT7i2p/qqSjHF8mC1luILnTE=; b=sr/uvI2+hc2jYFoRTJO/r7T6HfXzvYih+4daVUlm9kyKPX7rEbhpfcOdUjMBFoCCmn CTMeWlxo/gm2Huq/IqFDgi0oDYO0NgxK0dq9hOla2dUrAj+WMAUGZ2xH8qqK/C5SeByj yr6GRfO7ZFEa7otk5hI4N8tsQxCLwFzKJHjmeNHUw3vbrOR8MXrjjqXeKTvfkyzVEPzN aRhqT5uyyTMK01YL+l0Qq/r1KHAOYPVwIF4teIGQFADTEho7hI9BFWoqzbM+NH1l+3fA 63+XJZ3uFAvixzPnCGIs7Qg6fFBp621lOhOl9fNIs5RQtFiU/lyDw2z3ZKAaEwa0RhX7 7Jug== 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:from:date:message-id:subject :to; bh=ItzKNeVLD5pa3Oyli4ooT7i2p/qqSjHF8mC1luILnTE=; b=rtGJedlao/RAc9zJ7ZyPr+Mp/n3aLZFr1NmxdsvuUiQqu21tRVDrgcKJ/JS1dfaABv wtso3y9rRVSMOAdYEf5yq+bBKkRegvebz5grBXH0POrhOnGottvazqzvxMwdRKBjnJH4 gYEIE1MpJ4Ns4PIrh+aAVSZNw8tkoO5qnkjWJaWKBEFzvwqyQML8sjgfH2oqxq3i6StS 51jrf8CMWkFth0MwaKgcP0sus1gl8GH3C61DpE1MVxrVRoS2vSN3L2P2l2cLn/M8fQM+ GUnLRoAxL1cPuTT2T+Ap7ZMQkoXpn+l5KR5HMaRkjbZMPQ0DL+VUVr8bGsCPU42KUjky KNlQ== X-Gm-Message-State: AMCzsaU6ySdOquAjaurzHkYhzcKp/6dtDpG0miTMRVU1OvCxwvyAaeot Yw1FOGNaCQwwavSKyq2JOiYPhYAGNQEWJAQNoZfDhqiQ X-Google-Smtp-Source: ABhQp+TiJxxjQTb1yhQRZSTbJ7ScF3JW0+kPYiM0zaOcLU7zZMTCqnJJedEbTIC38Szazxl4+VaN+JBTrk0uDpMiUTE= X-Received: by 10.36.69.100 with SMTP id y97mr10646775ita.50.1508785708040; Mon, 23 Oct 2017 12:08:28 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Mon, 23 Oct 2017 12:08:27 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:9c93:1751:a648:919b] From: Warner Losh Date: Mon, 23 Oct 2017 13:08:27 -0600 X-Google-Sender-Auth: NeRdIjXjI5KrKhapzN6XZdDlhvQ Message-ID: Subject: Removing sys/boot/arm/at91 and sys/boot/arm/ixp425 To: "freebsd-arch@freebsd.org" , "freebsd-arm@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: Mon, 23 Oct 2017 19:08:29 -0000 I'd like to remove sys/boot/arm/at91 (bootstrap code for the AT91RM9200 that works on a couple of reference boards, but not universally) and sys/boot/arm/ixp425 (which is for Gateworks Cambria 235x and Avila 2348 boards). The AT91 boot stuff is likely better served by Atmel's AT91Bootstrap + uboot. The at91 stuff likely hasn't been tested in several years, though I know one company that uses a modified version with FreeBSD 8... It's been disconnected from the build forever. It does still build though. I have no clue if it works owing to the difficulty in tweaking it just so to work on the AT91RM9200 gear I still have left. This was always a super specialized build, and perhaps shouldn't have been committed in the first place given how the AT91SAM9 line evolved (its SRAM size shrank to 4k, making it simply impossible to fit). The ixp425 doesn't build, and likely hasn't for a while (there's undefined references to memset, despite trying to avoid such references). It needs to be reworked to support the current tree layout (even before my changes to libstand) and compiler technologies. This is for the Intel IXP 425 processors found on the Gateworks Avila and Cambria boards. They were released in 2006 and EOLd by intel in 2009. Redboot is a possible alternative. We don't create releases for it, and it's not otherwise referenced in the tree. Absent any real users that would be affected by these boot loaders, I'd like to just remove them from the tree rather than try to fix them up an modernize them and/or include them in the builds so breakage is discovered sooner... Comments? Warner From owner-freebsd-arch@freebsd.org Mon Oct 23 20:40: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 E7F23E54A96; Mon, 23 Oct 2017 20:40:01 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 938A083C69; Mon, 23 Oct 2017 20:40:01 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id v9NKdrOR022905 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Oct 2017 22:39:53 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id v9NKdqpo022904; Mon, 23 Oct 2017 22:39:52 +0200 (CEST) (envelope-from marius) Date: Mon, 23 Oct 2017 22:39:52 +0200 From: Marius Strobl To: "Ngie Cooper (yaneurabeya)" Cc: Mark Linimon , "A. Wilcox" , Gerald Pfeifer , freebsd-sparc64@FreeBSD.org, freebsd-arch@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <20171023203952.GB51868@alchemy.franken.de> References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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, 23 Oct 2017 20:40:02 -0000 On Sun, Oct 22, 2017 at 10:47:03PM -0700, Ngie Cooper (yaneurabeya) wrote: > > > On Oct 10, 2017, at 14:14, Marius Strobl wrote: > > > > On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote: > >> > >> 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. > > > > 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. > > 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. 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. 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. Marius From owner-freebsd-arch@freebsd.org Mon Oct 23 22:28:03 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 82F3DE56925; Mon, 23 Oct 2017 22:28:03 +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 520192A40; Mon, 23 Oct 2017 22:28:03 +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 B28ED2F80; Mon, 23 Oct 2017 22:28:02 +0000 (UTC) Subject: Re: Trust system write-up To: Ian Lepore , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> From: Eric McCorkle Message-ID: Date: Mon, 23 Oct 2017 18:28:02 -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: <1508775285.34364.2.camel@freebsd.org> 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: Mon, 23 Oct 2017 22:28:03 -0000 On 10/23/2017 12:14, Ian Lepore wrote: > Any thoughts on how to validate executables which are not elf binaries, > such as shell scripts, python programs, etc? I hadn't really thought in depth about it, as my main initial goal is signed kernel/modules, but I have given it some thought... Arguably the "right" way to do it would be to have the signing mechanism be part of the platform. For example, the JVM has conventions for jar signing. Not clear how this relates to shell scripts though. An alternative is something like the NetBSD veriexec framework, where there's MACs for specific files. That stuff is mostly orthogonal to the public-key approach I'm working on here, but there's possibly some interplay. From owner-freebsd-arch@freebsd.org Mon Oct 23 22:41: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 AEB1FE56F21; Mon, 23 Oct 2017 22:41:36 +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 88048339F; Mon, 23 Oct 2017 22:41:36 +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 B733A2F8E; Mon, 23 Oct 2017 22:41:29 +0000 (UTC) Subject: Re: Trust system write-up To: "Simon J. Gerraty" Cc: freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> From: Eric McCorkle Message-ID: <1923f560-debf-b913-5cd0-a349444e451d@metricspace.net> Date: Mon, 23 Oct 2017 18:41:29 -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: <67125.1508777074@kaos.jnpr.net> 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: Mon, 23 Oct 2017 22:41:36 -0000 On 10/23/2017 12:44, Simon J. Gerraty wrote: > Eric McCorkle wrote: >> That is also an option; however, I prefer the configuration where only >> the local system key is a root and everything else is an intermediate, >> as each root key represents a source of trust that is hard to revoke >> (you have to power-cycle). It's almost always better to have a single >> root, and make everything else an intermediate, though I'm not sure >> enough of that to bake it into the specification. > > While we as an embedded vendor might not necessarily want to support any > local signing ability - or to be able to limit the scope of any such > ability, there should be no reason you cannot allow a FreeBSD.org root > cert to be honored in parallel with local root. This should allow > updating system with both locally build s/w and pre-built packages from > FreeBSD. You could do that. You can have as many root certs as you'd like. The rationale behind the "preferred" configuration is that it's simpler (fewer attack vectors) and it takes a stance that users should have exclusive control over their own machine. But nothing stops you from installing any number of vendor certs as roots. > > FWIW when designing the trust model for Junos, preventing any local > control of trust store was an explicit goal. > With the advent of secure boot and TPM's, there is potentially scope to > allow for mixed control. That sounds similar to the high-security setup I described. > Please have a look at stevek's mac_veriexec patches in phabricator. > The verified exec model easily allows for "signing" any sort of file, > not just ELF binaries or needing to use special "attached" signature > formats. Thus it allows adding "signing" with minimal impact to most of > the system. This could probably work well in conjunction with your > trust database. > > And of course my loader mods follow the same model, so signing > loader.conf, modules etc is all simple with minimal impact to loader > itself. I've seen that work. The NetBSD veriexec stuff is of interest. I don't really see it as a "competing" approach, more of a closely-related security mechanism. I don't see any reason why both mechanisms couldn't coexist, and there's probably some sort of beneficial interaction between the two. I could see, for example, veriexec being used to protect specific files from tampering, with the MACs themselves being provided by a signed file. I'm a bit less enthusiastic about veriexec in the loader. The problem there is it requires an update to the loader every single time you build a new kernel, whereas the public key approach only needs updating if you change root keys. (That's really the key difference: veriexec is an anti-tampering mechanism, where the trust system I've described is a trust-delegation mechanism). From owner-freebsd-arch@freebsd.org Mon Oct 23 22:53: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 2C03BE5735F; Mon, 23 Oct 2017 22:53:10 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0134.outbound.protection.outlook.com [104.47.33.134]) (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 B3FFF3BF3; Mon, 23 Oct 2017 22:53:08 +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=gL7yP/zlyheW2y6AMkUzAYLenl6Y/1mSP8BNcXkHekU=; b=g+txXp8dUJNVcuXgqnIVZRS+qnMG0U6q70skpVRHgModiRdorjGO8AeaLfq63AafcOaCKc7OpqaEtOWE1ACkNwZSUh63ZPjhCYHjtPa9gBmNY5RkNFlrwJDymi65snE4WM87bPJOlXjAqExGc5Mi/jQvHfaFzIYgpvgqi8QPBjw= Received: from BY1PR0501CA0003.namprd05.prod.outlook.com (10.162.139.13) by BN6PR05MB3012.namprd05.prod.outlook.com (10.173.19.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Mon, 23 Oct 2017 22:53:06 +0000 Received: from BY2NAM05FT037.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::201) by BY1PR0501CA0003.outlook.office365.com (2a01:111:e400:4821::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.2 via Frontend Transport; Mon, 23 Oct 2017 22:53:06 +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 BY2NAM05FT037.mail.protection.outlook.com (10.152.100.174) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 22:53:05 +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; Mon, 23 Oct 2017 15:53:05 -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 v9NMr4LT015550; Mon, 23 Oct 2017 15:53:04 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 29CAE385567; Mon, 23 Oct 2017 15:53:05 -0700 (PDT) To: Eric McCorkle CC: Ian Lepore , "freebsd-hackers@freebsd.org" , , , Subject: Re: Trust system write-up In-Reply-To: References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> Comments: In-reply-to: Eric McCorkle message dated "Mon, 23 Oct 2017 18:28:02 -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: <72902.1508799185.1@kaos.jnpr.net> Date: Mon, 23 Oct 2017 15:53:05 -0700 Message-ID: <72903.1508799185@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)(376002)(346002)(39860400002)(2980300002)(24454002)(199003)(189002)(50986999)(76176999)(4326008)(105596002)(46406003)(97876018)(7696004)(6916009)(69596002)(2950100002)(2810700001)(50466002)(305945005)(81166006)(23726003)(68736007)(81156014)(47776003)(106466001)(8676002)(50226002)(356003)(478600001)(53416004)(76506005)(2906002)(8936002)(5660300001)(229853002)(107886003)(86362001)(189998001)(97736004)(117636001)(54906003)(7126002)(316002)(9686003)(55016002)(16586007)(6246003)(53936002)(6266002)(97756001)(77096006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3012; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT037; 1:5lJiF6R0vHAsKDfuqb2+3kH0xb8WP8vB4mkUgyffEu2FZ2sejv5TP+BQoLP+sbYTD3d0kfvtZTEYhh8aYmuP/s2SxWdzikUa9w6XjpXyhPH89pMlNrzz6g01HZbMwq1b X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ea03b818-4e0d-41cb-a096-08d51a68d2a9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR05MB3012; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 3:dMgwDwonGgbA4DypvWJOlt/WLcRJp93C1OhdCdwlHaaQbbVe+1/oHLkS8SipU3WRn0jBEEXf36SXKxtQKEBz65SW42KufjTTLmNyQMdm6RW4zJIey3FRxmGOjln+NpL8G7WEwvLeVXhRK4NjV4brlz6XuCOu0skftdK1SZGLSzGT+hQ9omQFqGiNCnrKkGxmSfAbOdj6uox+Qy/A8DytZYq5A/uA1K9vrVXwmKvZmlZLFu5fOLID39Zmw7cyOvd1oMKkWPYMzlAMWnrh9m2sNpwH6qTpc24sTOHbn8dBuztsm40WL+0hRlTYI/2KMsgBg8L5o1FKZPXT/Qk30sRJM6Ezlg3bFGogj7EApyy3fPQ=; 25:9kBWzNzt4Dvpf5/1sJkDwBBC2zx+TYXtOb2HY0QMiVj0gtkQqTLc8L1W6NDBjRrGnOb3TkYb1QWgeotEV4zX6k09d0uJ7/5xhNUhQj/6jWFimP2MbvpIpCn9HrdRofYg41/GfvuhuTlcOZ4wDAkJC0gq+pdqtTBM98UCGVoJbME4LyLDfE1t54Jm4Z9PpaJokleAIgcdS/T1pQr4VZ4v8Vo1XGcfUpsap6ucjajRRwLpxkqGX8WvurF6Fygyw4fCNSJpRFD46GwLMFaSFg3YRQ1D/EByEM/PljrK0DNThWWeKHdVZKY4hCNGOWRfff02eA/OzUNlZLBQUU8EE56m4J3HWZwUwQKV2ptHGUYgWFc= X-MS-TrafficTypeDiagnostic: BN6PR05MB3012: X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 31:27pbbRLJkKVTUAU8eICFT1zeQS5Q/EJYrfAcGHX7Z7jsml6qlVnDmEVYGhoz/dgF9WhE6tSAIM5170RP8KDJJ3dhLXY6iOs8G789IdjEDefbB23RUvSUu0xokuLQpToR6gN8PANmp4QccmTd3XzkAn2yfacQVSWQHt95OnGgbWr973pu8EIM6ep0sTCgBNXR9k21tLhaLl1+PWsuaviPNA+o2NCDXQBMLnLY+l4c7lc=; 20:1VMgI5TTgxM0pmryAlMQQiQsjmyDE4/6YqoAGkS3q3pYUlaRXgk57MSM3npci28N8h6oVKINA06wSmJUyUvDoT8mF87Zn+mL/wkIgeG8yRYT+TkCqZWOLeaHSQe0ymUCN1GgIa0SPbEnS8M9F2gGKRgeuiZkr8GJz3tJHmYo0pprGNnPnxvMWwWb7R11QC3pDUdrxJu+4+Xe8W2bW4ov9t0K7TA3kVRBSwtetPgGK7p54weykkgHGy0k+PJpRRnRsR/wStbCF4Xe9fWBjwqqKQ9Xh+qdrkfYDxnKEIpDo6b4kxLAJFlwBicpTLbFW+cGnWuvkm35pRTTxdC1zTFrryG0/b3rDRGGJ222snpBwbWemHAOo7uWBt/dWuyMkh6V1XNUm6P0XH5jPqsDu+zLQSye8tUaEfapRRYYIpIXzTJ50wa7UDNYU56VYo6FIXxbPL/7pJFm3tZn+rSp0ST/MJdckGtjuJAA7c3iRPIQ7F5hK2Le/vm8/A2DHwOAftON 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)(5005006)(8121501046)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3012; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3012; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 4:4Bd8ehGZAtnIbEXO+/Dcn/9fU1qJyT1ALvlMakdQW0BfmtFx/Q6IMpYWvONMihbrdSz3LwAfKV/ji8hUlZ80aDWbXo9O9W42PD27sYYz5VkdqjZJvH/cVk4B9hZQeCKHW6EKddLicLc+9NPVV0c+zTHlJHI/AY7DCm5ILC5KqSiBBcNChRs0ZYdWxE1Zl6g0s6GnGu2OHtMupdEUHJzvzBbUXbSG3dTVMeVhRyT21yM4+95TtM0q6D4YS9cU9b+I X-Forefront-PRVS: 046985391D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR05MB3012; 23:2kUZ3nPRndR2j3HQUmgN+XSe7N80N5pxeMwIEwfQO?= =?us-ascii?Q?K1lkehWoyQfZ5JPi741lT5MKpUv9iNSL65j5KQyW6XOVJWS2HONwfcfIqfSE?= =?us-ascii?Q?X3rP+AWhDLjUNoD9Iy1q41+wXnMjt+WVVbBmIiMa9Pegej9c0Up6uW+SkwW/?= =?us-ascii?Q?xy3g+ZeFYewr9SIubJRjBObGfz18JBAq65w17bMGWqDKgWGIOONIMUlICP6S?= =?us-ascii?Q?nHzB6suYMHerPDnLp6SO0bJrzdbzBcMPUDdYkPEnpDJC1Xvon5qON+eLLg4b?= =?us-ascii?Q?teZfEMdqGDIZ8u+dz1t1ehwhzhE5mH34GJk5VLPblVEqmUgAcSAytAXAElwZ?= =?us-ascii?Q?FgrsX/NpsHlzNsiApouwBpr2X0HBQqjzVIvoNYxsjVIBmsl1oDFDSXT4PO1j?= =?us-ascii?Q?Pkw4x8oOrEH9ynwtmZGIwxfN28sK0v84FIbWiUjJaDKTHq/PbJkjQ+gvPwXA?= =?us-ascii?Q?88Gcq/CaqdZ5OgATksOv/8M0M1mdSnzlwO8mr7vlYc3QqEkNvp5ui/sRX6ZY?= =?us-ascii?Q?LPFJvpRwxEOLvPvPlzLE6MU/Jr3lzt83UcKiskck+rkAx/6NQZ1+GKR99cLO?= =?us-ascii?Q?44TsClPe5hJhbt0ixz7O26quxv6tuiy828LGHAMBWj2IYzejCtHcNi4OErad?= =?us-ascii?Q?fwLSCnbesmylClBOl1oC1y0mnMSNXN2hj3tlEiDOs8IQjYyh9wwDbHCHC92+?= =?us-ascii?Q?t6M2AENHyyrudF/pt5KvepDWUItoXqWmxFbolh9NPyoeJa6u4fBqIE3y/i4q?= =?us-ascii?Q?mk/RPKzGdgzDMyVMGdxoayCR/zvLcua7IiDy69S0i5SVsQlFkb9E/TBmnjqQ?= =?us-ascii?Q?+LY99mTiQAifBhMEgwQaRua9yFYprC806c1nU1malK92u8lVxR8XccYN4nm3?= =?us-ascii?Q?cv5PP6ftehtRnrWmE52j9f98Vlm7by2oiY91daNSRch32Wrz+rSAv6Hngg/7?= =?us-ascii?Q?QjWxZSHgq/mpPbVbZLjls+g461gzufGRvs828tB4m5cTudzGF+jaf1RGZQ1V?= =?us-ascii?Q?1Yq4GWEQgdDYImDAHNDiTWL0DxqblpF2QXMZe1v02iBhpukaDCDCoS+MU7sy?= =?us-ascii?Q?05CxxtRzAVguz6+XXg8fcU6x79OGcx6XTunV1IcUx0YHX79E+6OIDJXHFFPC?= =?us-ascii?Q?o7iW9msaqJcJP504Va39qiHDYtg7hkbYaAwmuM0p2g66TBqmGKMICYZ7o3jt?= =?us-ascii?Q?iL/2i00BqaE0TvGte7krSN0SSw+QV7qwaONXwl8S0q2axCNbxliKXUwcqc0s?= =?us-ascii?Q?PbCUo4uXD/lvTZtd0U=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3012; 6:brZ9nsuRsrOq5KmSpuuGtCM0V4sPmmdUklsBw5odC9hyrLrpzgCvRZuaVbUHf1udppt9z9vACH2/O7GUiSi37A1hZyq6jMXjZVEyQ7Q4wPbwNVxPdx5QNjxE3ibv+0aOMRMVve+tXoM7MbXEIJeDf5PDeleGjXntuvArnvUYezfn9I23w5Fy1snt4uJLTwmdkZaK49Rdm6O9NJVb+VRhMJzfqUju+SSa0itDDttbWAhGKvrw0yqk0kuPCK2Iqyx12CrNEsNNQLa1thXGIos7ZkDYmh4D9p8I7YyzJoomStVpbQOhOsmjGR5NRr1QP11be80j4sesOMva1Bk6b3Y09Q==; 5:Pp9fw2YGFeP9+MRHfff0bvFe5MHIgrPkGmf3BCX92KWRrKQ+PQmrfRb1s53WUOVfUfh5VwXplSNJUVP09vITSmMeVUrLSmr0o0ORvExToCZlcA68q+ys7F0vu1yQZHrunJFeT5M/b6KgCdZxRdaUKw==; 24:X9QyNlQ6eY3+yAS6VWm0qtudtozFOrpr/FKai/+77nEfvvT3WYnzemgcihe4846ZbW3txqmgiwhLV+gSjcw1GdXWyVmVbCmxtjXud2I+a9A=; 7:7i8VKfrFK2EpPAKeAz/eSwcOkYNveEdMGB7gRFL7lhb+KGQqR95fvAV2qZXoFmAdARuMx/lZE9odW5Qo06g7nYTkDW8QRjIISzD0/AiHdUclIzAeOOtNkukX5ynMfPl+GMu9dIgslK9NOvYSeTCMiF9X7fiez81lA+M4ZRYZ/3BEBtNxtl9B+Wj1GVAk/OPfwrjD2/USP7K41EaVskQCm/X3yMnb3RgSZingVXatgCc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2017 22:53:05.3702 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea03b818-4e0d-41cb-a096-08d51a68d2a9 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: BN6PR05MB3012 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, 23 Oct 2017 22:53:10 -0000 Eric McCorkle wrote: > > Any thoughts on how to validate executables which are not elf binaries, > > such as shell scripts, python programs, etc? > > I hadn't really thought in depth about it, as my main initial goal is > signed kernel/modules, but I have given it some thought... > > An alternative is something like the NetBSD veriexec framework, where Yes, as previously mentioned the verified exec model deals with this neatly, and btw is more efficient than signing individual files - as is needed with ELF signing etc. I think for linux based platforms using IMA we need to generate 20-30k+ signatures, vs about a dozen for platforms using verified exec, verification is also more expensive I'm told. > there's MACs for specific files. That stuff is mostly orthogonal to the > public-key approach I'm working on here, but there's possibly some > interplay. Yes, you use the public key stuff to sign the manifests containing the blessed fingerprints. This is what Junos has been doing for more than a decade. Your "trust" database, might be useful in being able to extend that to general use. The trust model we use for Junos is deliberately very restrictive and thus of most use to embedded vendors. From owner-freebsd-arch@freebsd.org Mon Oct 23 23:15:38 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 E8818E57E77; Mon, 23 Oct 2017 23:15:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0090.outbound.protection.outlook.com [104.47.33.90]) (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 654E2642F3; Mon, 23 Oct 2017 23:15:37 +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=bpfZjxVg6JF7BOp7G6fWL6NSDMq+OVGKrzQwhZzlddU=; b=EvRYCeqbB16KsODRcu/spbodsBiJgoFJPL8BLBr8WY/Lz4qziQyGCBDEt3bz3LOVbdhNYZka8nblvqaSEpOs9ot358Y9VT9Vqv0mygGYYlNXbL/gt5GwsElvOeKP8c1pKGw3LXLFi9nRRQGwT2Az1bYEAWjcYhtspQbFfgGkWr4= Received: from BY2PR05CA039.namprd05.prod.outlook.com (10.141.250.29) by CY4PR05MB3607.namprd05.prod.outlook.com (10.171.244.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 23:15:36 +0000 Received: from BY2NAM05FT019.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::207) by BY2PR05CA039.outlook.office365.com (2a01:111:e400:2c5f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.2 via Frontend Transport; Mon, 23 Oct 2017 23:15:35 +0000 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 BY2NAM05FT019.mail.protection.outlook.com (10.152.100.156) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.156.4 via Frontend Transport; Mon, 23 Oct 2017 23:15:35 +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; Mon, 23 Oct 2017 16:15:21 -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 v9NNFK60020696; Mon, 23 Oct 2017 16:15:20 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id BF0A2385567; Mon, 23 Oct 2017 16:15:20 -0700 (PDT) To: Eric McCorkle CC: , "freebsd-hackers@freebsd.org" , Subject: Re: Trust system write-up In-Reply-To: <1923f560-debf-b913-5cd0-a349444e451d@metricspace.net> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> <1923f560-debf-b913-5cd0-a349444e451d@metricspace.net> Comments: In-reply-to: Eric McCorkle message dated "Mon, 23 Oct 2017 18:41:29 -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: <73295.1508800520.1@kaos.jnpr.net> Date: Mon, 23 Oct 2017 16:15:20 -0700 Message-ID: <73296.1508800520@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)(39860400002)(376002)(346002)(2980300002)(199003)(24454002)(189002)(305945005)(97756001)(356003)(68736007)(77096006)(8676002)(7696004)(117636001)(229853002)(50466002)(6266002)(6246003)(23726003)(4326008)(107886003)(97736004)(86362001)(55016002)(53936002)(9686003)(5660300001)(16586007)(7126002)(478600001)(105596002)(76176999)(2810700001)(2906002)(316002)(106466001)(76506005)(53416004)(81166006)(50986999)(81156014)(2950100002)(50226002)(8936002)(69596002)(6916009)(93886005)(54906003)(97876018)(47776003)(189998001)(46406003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3607; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT019; 1:2qsTOlgJYkWcdIwfd4JOJ+Z2fI0/DqP6KsoqJHXIK05iIQrEzAi+aT59kWO547PgYziBZUnpYzsP8EmdiN1rG9Cx3J2SqwH0tASB1sUNiDQNitH6O1/gCEniIzuAAqoD X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c120c167-01d1-4cc2-f3be-08d51a6bf777 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:CY4PR05MB3607; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3607; 3:Ke37Bm0FJhdwoAQ3N/gfXPDdiLoSK5MONeHntiChzQO8UDlnmqOP9oTnrKQxR8qxeAWLvTc0ESvMyBH4xS3xvo0+eqEP6bDtjih27T0hla/a3HTwOUZ2j0nqp3Spe4QFWORMOzIxEhultzpm88ZQTVVsPgfHaayNWGWVoRAovvo/jJcB5j0o9jRh9477MUTaHQcb7/oXW+4i4WtHWgk1bH+7w9MX/2Upj3bZjITRu/yv0rMNEkC8fUNuPIViy9kvKsrRjz4u1p7kypGzhgSLdJOvt77Jaah6FpLyx7XA4xbfa1iY3XTxFg3hx4puL3pMP4PpwmL0RSFZSUxcBsAlNry3P6ST2IMvfiDLQ22zihw=; 25:fA+uVwwTc1DW27XpA5RTlV9NICwS+LyuU/q5KPjgPwRv+wd6j5LHPYC61+K+mcku6QFXh6KoAxYShMalcaT0VRNOgZZ18omirUIOxo9BZ75AHhI8rwuPlWzADZKY5LcifHmlVmBcgQWfUXg25Nm+g75nBSSZUbNzsGrSFYh9L/dAd8iIhJ3eSxifj6H9g1j5rl/sB3+PeQQNbdjVcZfBOtL5pey1RSgbi6ZJk7no2MoSnhorebolBl2R79Tw7GsLmfdmI6k7aamzZVVsMHh1LvniOYDEumUGUI2/NuZsP29sVNtejFFZ8DKM27w7NXJgzGcvbIwAdPBkIAsVsBEAPA== X-MS-TrafficTypeDiagnostic: CY4PR05MB3607: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3607; 31:w4CkATwTztXIkm24WZS4QaSAKUuosqfG+6yUujfkduLgzmpYuYBY6S0ljM8Y4eRWSA5P5ALl+pHMUMUWKxGkwdvLY5Wvr2bP0/B2be6pOQw6KqcxGIPcTxWgsXPyqhlM2zbWGEloqQbFum6ACpsTAcwLPKgsE/v41MRILaV8LpOUfzluHwlS2L/8SetY5Le79K23Fwerb4qknpjLqmuukuuXSIqwkmfyHB5JU5d9M9M=; 20:pKJ768HlZkN+1MUMxYoD9scay7IiXewmnDw0gPK+fVosVv5KQcsSOt6Y6Qz1z1ySCBMH0budGBWwKtnXkkd3oM35tLhrhtMIZF0UTQWMBTimtB7w+TzMbyR++FSigVUzFdEiIzH/mTwYCaRcgGOIgRG94o5kEugYhfbaP/UYaJ61VFWlS3PP6vUiTPoNNTrEXeLAP2YEmqd4WdtXB5RnZs2nceb+2dXcpisFYqHchQUj0Ljk8lrlaaqCpAWS25c6jHaDMk4XQjRJUwihxZ3UrPsnStIZ0pPF6bwOwcPKppJ9NnR+ZHPIl8AkVf2LofvezfHf67RHoZl18mocR06HKsyJ4qzNVraiwHK6udY5oTPo3bYoMLMqX8+giqxe9nEOXGnopKrve7KWU+gTFSyN39A66bfytId9JVeaPZmAmwIJhxPEJzhanVsfwo73KlC6Y2+aoyI0SbvUTWL7+bzjMQldhJ4IWoS2882iWvfyhtb1u6Z8PfhPRkpb+lQwWhvi 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)(5005006)(8121501046)(10201501046)(3231020)(93006095)(93003095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR05MB3607; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR05MB3607; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3607; 4:fTcub7/5gis2BZNGIm8GU+uEuCeW0sQ1xicyjd5jLn9RUXhN/Ey0YpOSTQeZFdkWGYFuT8xWOMkk++JXM7RdRyR6uI5TFrC4ONAbYhJyO9pkxqNYRIhFopWLRh10ADuSMS6AhE0PkOl+5hmc76O+5HwW4eq7cVR1iVGvAaZexEgwFTJ9exvLXGnn21xHjpmQ8cTqlS3MYJveqX3JHrG9WkKFhMrsE/o7z2AsSNQ6RbDnp1XXQhmET3P0N5qMOQt9TPaGpW2BneXW2MNyLnK5VA== X-Forefront-PRVS: 046985391D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3607; 23:YsvxPENMmT8Gpb1zvih/+oVZxEngBMkJIht/cNBFe?= =?us-ascii?Q?ilKTnvY6ZBy1G5JsA0Zjl0jthrl7l0Nq7uc4nQC7UnCg64YPJau4ZjlccCMs?= =?us-ascii?Q?zu6VFZCxP5IGpH4B9+s502Q1555J7TVnJNYWg2Mh087IVAGWN4KkFzYA1ME7?= =?us-ascii?Q?VIW7kz6N++dKfk/pFCn7upGXn15W6hxkKTyWKwnvFraxOLzaT08D79W5R2UQ?= =?us-ascii?Q?o45mEjy0J4CmF0qvW/WqOW8yjLJbHOs259rIqF4PHd+N/vbRBvKBZkw2iKv7?= =?us-ascii?Q?nnQXrysxtW2IiN7Yxa1edvx7HYdNexD2JmFrCnR7kdPB172VqO8W8+fSJbtY?= =?us-ascii?Q?cqdYxjAfworKzB6Ysp8wHvXAdP2yjrNz4TxMW3tORk2/FYO5nU7l5DrNjijX?= =?us-ascii?Q?VYMA5W4JRljmB2lf3q6Rh0SaRkZimSXSY0e2yn7Hv4mp+XmmdJv/VVEGDLYY?= =?us-ascii?Q?Kkf9bmcxVzgFeAK4pr8XRcB5CjjiJ2h1t16TC2SSeH2aWrQ/on6alz97YdJD?= =?us-ascii?Q?4/YsDzmkNy/cZ8iB0x4MCV2WGK9wHkXAy3pctpxxnB2b8ziQaZXJH2cnt/7z?= =?us-ascii?Q?Mzezt+YQ2v7wutzlY6OV8bzx6oJ092QV3jyxGd2Nkt2rWYEv6hDoeTp0y2XR?= =?us-ascii?Q?KWjcVUA0dDIWKvmq31goj5ZfOQu+Iv/J9ls80TAkLwLVBFuWpW1LjEulG0at?= =?us-ascii?Q?DmGRw7cB7X9Ag2dJlzNacQD2lPVp9Or5bbByI3D9AhXMCMNobPlttqK1ziW6?= =?us-ascii?Q?t4+Jwzij8b12Iz06hqJWvCSe7CPvKIiaKwNe8i3xmtfP0qRR8s88XzT88uEq?= =?us-ascii?Q?XoyjBxC9pWgLCbv0v1d8nO52X7ya0zQoO40JhVTxzWcXHnM/I9OZiuqoIs2o?= =?us-ascii?Q?yN0zbJN7/gxyW8O3E0Yexh0CNXJnWq7qwKdA70Jk6nPVqAYWq+r174XVtCnE?= =?us-ascii?Q?FLfhV00NGNm8Z0JhYiOME/M20gAObcJMb4Va/e9XRWmWTJtQACgCmS9fvYVz?= =?us-ascii?Q?1H25WMDJjEqMYR8BMhEi3TC0Nxk1FZDZjIZicv2tVKK5QsKACX40VmYpCof+?= =?us-ascii?Q?KJeMjpkKgHDMzil/Op2NXWQSHQywpHua7FzvZRa2pDYxnQYBaoLjBtLAyix1?= =?us-ascii?Q?G3uIsGJxZlUvLTQpPo+rIRJHTJUOCI4RIfYzZjyrwHL+hET69tLSzZl5LkgP?= =?us-ascii?Q?qNLfoksRsA21fjeSCZlNhjJjnleP+NFCK30yrh/HenDW1rmC9lNQ77CLhucl?= =?us-ascii?Q?UVTf3RM48gONZflJ+UkMXTnk0Tfwcdn4Apx2N6Y?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3607; 6:lz9gbF0F+5OylRqbfc8oPxH948Av9NuOfaJQps+1DXlh+Uh3OP1OZ9ccXTFe8ROpPD0Q+HBJrUAEULyw2Ow7JQ5sM61cB1yRug00D2ONCFberHsv/xvh2dYca5J8eGmGDdJXKXg5xn34n1vmY1SSAsg4ZRptunlRs899AnGYS613Vp5GgMUMldt1j43Yo2crFTDHZ511Uf7IUk6jksI0VB52+ITSjYfywh4+5+D1kjsWJT1tibt2hd3M009z0KBzUuMNRl6pTsUs8Q6d/rQ4+SnfytjLvuqISP81osg67hWybDOcTe/71KFHhPFfm3UuSMA+iCeB6S6ZQtd9Tf1FqB6M47bPFbwYfE6rozY8vRA=; 5:3sOP3j/SLDeWbhkveNegUpRxiMcXhV6/ZydgjsCySBjxeolM3Hj8xAXLtVK4Izb8QKXYlzrZ4Gppf81jQo5L+3w6S9QXfmUde+UYY4m2JV2AS8hXJrS7kp6BZvb3EhxXiu/tyOFRWLfQfivgm6JJ/gqUkogdhWEzYu5Ouxae8Ss=; 24:0BsSYP8Z/mkLYLzox5cgUQB1JRpZdzxsp88sr6RpnsLLdguDKByay5/Fr91iTD0E2/hHmiODGDekFaRkx/zvGaIOayFAKFyXkEnAlUr+Ouw=; 7:UPbTzekTAoSi1edcY34dABn6cEOpzCGvDK2XvOb/HQq+B5bmcfl0ERSbhm7NNRZOLUegTbVcBjgN9toOFPYSXR0qsH5Meqvib9KBghOaRGHuk3N/iUGarlvj0pbct82UsDkt/KwlJFGrWM9EUNe1SjEg/wHNuc2vl1o1rvg9atbfccmQXVY1Y+L8wuzg0d+ktveIO0Hv9QN3Net1LUrpLTiZ0l/QbG+9CQhMamosbx6fTLknsfkHA9bVNxI7X5gl SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2017 23:15:35.6261 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c120c167-01d1-4cc2-f3be-08d51a6bf777 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: CY4PR05MB3607 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, 23 Oct 2017 23:15:39 -0000 Eric McCorkle wrote: > I'm a bit less enthusiastic about veriexec in the loader. The problem > there is it requires an update to the loader every single time you build > a new kernel, whereas the public key approach only needs updating if you No, that's exactly what you don't need to do. The whole advantage of the loader changes I've done is the flexibility of verification. One loader binary can be used to load any Junos release we've built in the last decade or the next. The only time we need a new loader binary, is if some code in the loader needs to change - or a new rootCA needs to be supported. The root CA is the only key the loader needs to know. The signed manifests have an associated certificate chain used for verification - exactly as we do for normal veriexec. > change root keys. (That's really the key difference: veriexec is an > anti-tampering mechanism, where the trust system I've described is a > trust-delegation mechanism). Take a closer look, the veriexec manifests can convey additional information to the kernel (not relevant to loader of course), which we've made use of to allow apps signed by keys given to 3rd parties to be run given suitable configuration. We can also assign labels to apps as a side effect of verification - labels that other mac modules can use. --sjg From owner-freebsd-arch@freebsd.org Tue Oct 24 00:00: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 88E19E2BA92; Tue, 24 Oct 2017 00:00:55 +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 5F6CE652C5; Tue, 24 Oct 2017 00:00:55 +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 13E7B2FC6; Tue, 24 Oct 2017 00:00:54 +0000 (UTC) Subject: Re: Trust system write-up To: "Simon J. Gerraty" Cc: Ian Lepore , "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <1508775285.34364.2.camel@freebsd.org> <72903.1508799185@kaos.jnpr.net> From: Eric McCorkle Message-ID: Date: Mon, 23 Oct 2017 20:00:53 -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: <72903.1508799185@kaos.jnpr.net> 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, 24 Oct 2017 00:00:55 -0000 On 10/23/2017 18:53, Simon J. Gerraty wrote: > Eric McCorkle wrote: >>> Any thoughts on how to validate executables which are not elf binaries, >>> such as shell scripts, python programs, etc? >> >> I hadn't really thought in depth about it, as my main initial goal is >> signed kernel/modules, but I have given it some thought... >> > >> An alternative is something like the NetBSD veriexec framework, where > > Yes, as previously mentioned the verified exec model deals with this > neatly, and btw is more efficient than signing individual files - as is > needed with ELF signing etc. I think for linux based platforms using IMA we > need to generate 20-30k+ signatures, vs about a dozen for platforms using > verified exec, verification is also more expensive I'm told. Hmmm. There's advantages both ways, and I'll probably end up supporting both, as it's useful to have an in-band mechanism as well (also, I've already implemented signed ELFs). However, there is a definite advantage to having one signature for a huge number of MACs. Moreover, as I mention in the paper, the most feasible quantum-safe signature scheme at the present is SPHINCS, which has signatures about 40Kib in size. That's pretty terrible if you're signing each executable, but if you're signing 20-30k MACs at 16-32 bytes per code plus a path, suddenly a 40Kib signature doesn't look so bad anymore. It would be pretty great to roll out a trust infrastructure AND viable quantum-safe signatures. I could also see a combined scheme, say, where ELF files carry a UUID which indexes into a MAC manifest. From owner-freebsd-arch@freebsd.org Tue Oct 24 01:10:33 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 F3409E3087A; Tue, 24 Oct 2017 01:10:33 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 7E97767434; Tue, 24 Oct 2017 01:10:33 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id r129so22123855lff.8; Mon, 23 Oct 2017 18:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ZboOZVl0nIACsuyzxRDNJSmPYeLUor75y7l61mcEXjQ=; b=XMO8Z1GuBMQviChZeFizydHK9VZCDVtOyq4fy9ZeTz8Fat6O9wstwhnRbkMBjLRLyS st54s4KkUll8UGOeSDqDgRzc08m5bZQtC330CNGojrBKbd7zYuuYjKJ2N9UDflAgbDhj AlytCgIfe57I6hSkahZgqi3PkEXImPXSMtasAfh48CsmhvKOzU5xr4pNjj+V8PwaHD1a 3vSmUWn+fY2NrQHcPMQqzTqEqOIw4MFE+3r4TbznaUv5y4Txaqf9x8gvvi5FWuFEvl29 H0HBBZJ4Tfm/Te56n4kL7MDEzCCJC3ckUmSNPUgJV783MouuNbTM7wJ1zwEDTmjCYD/u B8jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ZboOZVl0nIACsuyzxRDNJSmPYeLUor75y7l61mcEXjQ=; b=cCvPQ2LY8lNpPsnG2fdgZQd619fXDhwDD9HvemKtFOAP+doBkK+LoIyMhXsPhOMuNf qicKbbV3ukNsnkYq8iO/QDp60tycOYDQoLnPP/6/Sy0Qbzey0JJB4ilTqu15jBmAhz0C 73Es8gfjLgrhFM0fE/RQVIvO3FjD3g3w+Qu9dQHebfko3lqXKQ/BYAqPw61ppFLLn6uo oy942FgL1YX/r3xMJwP3uyHJ7169Gd0cDzPG+Qjn+HFadW06+Mth60s4SVgdM58SznUE IaqjwuklNTcxSB3mZmNQpLPBLh7MuikcJja420p+yirwUTf3/wzzLa83QX9ufnr6mZUr eRow== X-Gm-Message-State: AMCzsaXq3sqDGszMsBqrRIf5a/gGBHAH0OLAGEhATdyDnkeOecwd/FRf a3j/29ShlMBAN3rHw3WLP/M= X-Google-Smtp-Source: ABhQp+QytgGuoosSzODoCt+/3qvVlUwAea/azsslwU7ylOzRyJR1cwZYlBC2Dgc13gHslSCLzpQyow== X-Received: by 10.25.41.85 with SMTP id p82mr5897548lfp.186.1508807430911; Mon, 23 Oct 2017 18:10:30 -0700 (PDT) Received: from rimwks ([185.44.68.92]) by smtp.gmail.com with ESMTPSA id n63sm2283888ljb.1.2017.10.23.18.10.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Oct 2017 18:10:30 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Tue, 24 Oct 2017 04:09:25 +0300 To: "Simon J. Gerraty" Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org Subject: Re: Trust system write-up Message-ID: <20171024040925.1918f3cb@rimwks> In-Reply-To: <67125.1508777074@kaos.jnpr.net> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.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, 24 Oct 2017 01:10:34 -0000 On Mon, 23 Oct 2017 09:44:34 -0700 "Simon J. Gerraty" wrote: > With the advent of secure boot and TPM's, there is potentially scope > to allow for mixed control. TPM is closed hardware and software: you dont know what inside and how it works. Secure boot same crap: closed source with many known security holes. From owner-freebsd-arch@freebsd.org Tue Oct 24 05:36:17 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 4D0A2E406B8; Tue, 24 Oct 2017 05:36:17 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0099.outbound.protection.outlook.com [104.47.32.99]) (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 DB8AD70EB9; Tue, 24 Oct 2017 05:36:16 +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=n9QGnuj06Hd8EG54hzk1d4fKF58K1Lmhu1c6djbxGpw=; b=HZT0am190B0YUaq8u8VWNr2SzMICpX9qawX8DHeaucvM0jfKBoHcrk8JRRHd0PbqBLrusyqfJf5vDnkhBwJK2SEFDU4kzHH6Yo1gU0XD4q9EtHyvlP2hmU3SRp7dfXWYy1sgI/mnuZY9l+zyH3US1gC4GdfSL9tUCTph6gUqIdE= Received: from CO2PR05CA0061.namprd05.prod.outlook.com (10.166.88.157) by DM5PR05MB3611.namprd05.prod.outlook.com (10.174.243.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Tue, 24 Oct 2017 05:36:15 +0000 Received: from DM3NAM05FT038.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::205) by CO2PR05CA0061.outlook.office365.com (2603:10b6:102:2::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.178.3 via Frontend Transport; Tue, 24 Oct 2017 05:36:14 +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.156.4 via Frontend Transport; Tue, 24 Oct 2017 05:36:14 +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; Mon, 23 Oct 2017 22:36:13 -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 v9O5aCo1011296; Mon, 23 Oct 2017 22:36:12 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id D504A385567; Mon, 23 Oct 2017 22:36:12 -0700 (PDT) To: Rozhuk Ivan CC: Eric McCorkle , "freebsd-hackers@freebsd.org" , , Subject: Re: Trust system write-up In-Reply-To: <20171024040925.1918f3cb@rimwks> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> <20171024040925.1918f3cb@rimwks> Comments: In-reply-to: Rozhuk Ivan message dated "Tue, 24 Oct 2017 04:09:25 +0300." 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: <78907.1508823372.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Oct 2017 22:36:12 -0700 Message-ID: <78908.1508823372@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)(39860400002)(2980300002)(189002)(199003)(24454002)(53936002)(478600001)(2906002)(105596002)(316002)(2810700001)(106466001)(93886005)(68736007)(77096006)(54906003)(69596002)(53416004)(229853002)(107886003)(6246003)(46406003)(97736004)(6266002)(76506005)(4326008)(39060400002)(7696004)(81166006)(8936002)(81156014)(8746002)(9686003)(50986999)(305945005)(356003)(76176999)(97756001)(5660300001)(7126002)(6916009)(2950100002)(117636001)(50466002)(97876018)(86362001)(189998001)(23726003)(47776003)(8676002)(50226002)(55016002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3611; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT038; 1:a5WSeGAiCO1091HKG423vyan7LI1rI7quAjO/mDJ4bB+Esq8bdGO2BQhzxChlJZGWXhWjjcOgeuZkVy1ORFujVr0WOXOSiKQsyKg9V/ypeCKslksky1abMerdxGJofSy X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8578b3da-6ddc-4d7d-c163-08d51aa12460 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR05MB3611; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3611; 3:+vlqRFdr3FlR2ep+8J/TkWSzLeHh2kM6hm4Q51Y3+vECqdhcasb6IWRkWPxbnbH2G062JZHS0coWLXNde6//06gwvDywoJEH8ou1ZYLyY1cljOQZLa1F2mwzs5wKzpLbotQxCRt4y+L0fPSGnBh+PLP++O75UedSefb6wZ+3hBZtbmUezU1ZtY9ybG/7/PlWP20+zI9gV/fbRu5jQvZrUCUvG1olI3uHEdXEyK0V0d2/yox0VXCOa0zctqM9ZFSde9hA9oZgyexIGDKxOxlJe/0kV3+fzsU/Bg+LK3mn8gJnwzCjxyWLMxquUEJwWzdYxLMxoOWMPvGp0kxEJE6Mlsui5pjFIQNcIP8x67mtXlw=; 25:pAYFITFQJEW2iGKDXn2G39rzYHr9DtSm0/70PQe4wsknbsrHLisy+TDIspH9Qob7pHhA4OaEO2PzTaYFVL+65BysmoCdS0YDVJoN/vZybK1Dvew1OlVq+kBfPvfF7KVbnRV+uLP8SkzeYAFDMCIfZ56oP4IBvj2oKVl4xOo5Dxp9TEzCLvj4i+k+xfbx//Thke1XN0ndkGBMiLgYxRoojh57Nz0h41q4+Q6LZX7ZAwgH127NC9hNlrBpacGU/iY34Td1JnjBY9hU469ERL9UKXBeOY1iG19UpKS8Ni5qbDCb45IDZf4vEyGRqlo7R4cKnkVHp/hQmCy9EnhCKe+7rw== X-MS-TrafficTypeDiagnostic: DM5PR05MB3611: X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3611; 31:lYyVxan4FEY7dws6r5zahNwzmY5v+bwel5YUcIBDppIueRcecTalYwejKDuTe2gcqeN8Zk5vEPpMNJqi+qCDAg+Xv0hSLsrVx526Nv24Gm9z9NxW+uvr8PnAeaRzCAWJi2c+9Mno+IhXmoxTSzGS0oYdduWriJ0oBbcK78z5uV42CxdZ/sSC10+ofgXXbilLfDvtnAYRO7GMENR+zkIadE8u281RKP2sI3QWNdWkOPo=; 20:9vV2PuzwtztyHwdI3RmVsCRJZ6Bw07cNnILl8WHIC1JS8cxa9RCEZDh2tftrEZVNC7mU7KrmxZWUlDMxKN7OUMe4hbfZAXI1pEF8tKs4dtP6ETg2HMk/omjChj0g4w8qX0RAbv/v3RaErnY8ktZZ1Hk2oNtqKoqocqGBB0ObFArvCQSNsU3LdKs0JI2X+UCailH7gqA2k6fqV/XlwKROqlQQcIYcXpmJRM8AJz2nsRFEDN738S1CobcNSOwv2FHmSWoi8z9hM4LEdc0hkVwrLBSa9CkRdmuesAGH2J3t4AZLAY2zg6Ur1pmqZZwge1I7pudeS73kNO9B4QwB584+m0FMwdJuw+/jXmRMhBOdol89dtSuvmgpCtp5wk5DN/zHUtqgy1FIoY3qD3bIVNjLa1qL/P4hnxx27dWFqd80/4WAlb7rVSN5p4yLeCvxi+irpOx8JCPutFSO5D/1YoALr046EyfzYm/3xjCqFxrraKsqGMHwKRjpVjTuUQW8pNdv X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(17755550239193); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3611; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3611; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3611; 4:gPOtEK2mSJFiDlCl1KHFIkbJPDfZpLbukkrWx7FWl8hSr8xrdV/eAcEi51i3zbJ5z1jfb8BIl7UEMPDXQHSItnDIkSUbbCzj4INpR+L2ihaIJLaT8EmxjtwBkboY6bQUFRXlFvkCcyry6+i/HFPdvewzgIiCwxuH7xEDPXepRUaX1FWkuidLG13oCTNSQdjuOxDyNjC4rEauMWtGJr2TxDjYFpikcm7wcF1l3KojMfidjbkEybiYdUMoFQdvwcUiR3qYQMau4OOaMyA5rbXNcxyeFerol652pt+gc2Yx7xug6hNKvogOd0jcAMvdiahQj9BYEvg6auxR3HCCM+17CbHKC44S2RjUG0m5bMXM39A= X-Forefront-PRVS: 047001DADA X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB3611; 23:db3/GBvjFV/GtOjNeWU0IG7mLCkGUjtL0QLnXHvwp?= =?us-ascii?Q?fU/xTg/LDtfF4uA2bH8mFjmiS8cwVyNhL+Kf5+bbF4nL/C1Widu+2bNgcWi6?= =?us-ascii?Q?VVr59uGXIAKlyqKzSs/7We+ip/osr8jbIyYRnBDTu+AtHkLNqmrqboRedI25?= =?us-ascii?Q?hX9yshxH+PEcE74I6TKp/3Rec3Hrlnr5CbBx4/umMpGjUgbpX29CdPPxF1YG?= =?us-ascii?Q?7x103+G0rbrD+iO+TF1nClI9bHfGSOHBeDa+YxyMmgAvOGxWocg7LsFK6thy?= =?us-ascii?Q?Vei5tvTbD5/RgBffE2OzFaZHdwLOXe0Y7J6q5q5J+CY5Az6bZ772mwfbc0p7?= =?us-ascii?Q?9xRPWduDhr6S2UeQpS/gZI7fWxl9cRHtm6DBT+3mH57gFcctvaMj3FH4hCQX?= =?us-ascii?Q?PrDHU2SN8ybGGT6Fev1HJnARaB/i1uVmq/B6QLci1QJn1Uc7jWGFw3enPkXT?= =?us-ascii?Q?cA2G2WHogTfKCOZG4aSxOzH9LCUEcx5+rx/+jZRBhRR2FHywmIeZ/hTwsa3x?= =?us-ascii?Q?DqdaRc6s2sonof+JBMDVdc0tfPHA0aP3in9jVB+1wPjdC8TpsFVc9/8+k9ra?= =?us-ascii?Q?LNAv2ACzxBHMBSL4XU7WRZQQHIMXYB8W8DQgQDLrKpujyBHxBpUIzNxqXmzr?= =?us-ascii?Q?Euua2g7sDVENhO0tWC11xpx+hYqxsDd8mUB3TJ+321IasZuixsk7wq99TZOv?= =?us-ascii?Q?1dLKzlCs4Hd35Cq5GDoMVDh3Ep4llrUo+kvzQZKH8zZdxOJZrzl1FCeqz6yt?= =?us-ascii?Q?eEzFDGzToAcMwWRWJlMqQ/XBv48Wc+JFDi4dfDDj2S0IieaqT1Ijn0Hlzd2r?= =?us-ascii?Q?17Fzqwqa3D7FHhXAvdH0bsdupt9IxizSzXDYml8YTbMiMrQ5Viky8/ch1qSH?= =?us-ascii?Q?yMAAzILnwarM70rsGNf1vAZw1h7aSZ71LBnyCQKNFu55HzF87BJCPR8mOpYJ?= =?us-ascii?Q?as1CoEIlrjiwFwVUvMPO7Hguvh+ApdwRgeyeuSpudeQfe/K0NapW9RoSD/bS?= =?us-ascii?Q?qFR1fkKjp2ehjqSkhKNx8BPZ0L/lJ4YtmbcTIxoYE7v8XAKZopQ1TQavSG6O?= =?us-ascii?Q?KlaA6RbO8xungz7tYhYBqHlUFFBSoVP43lioszygYO2zbPt6zDxjN2m40uz9?= =?us-ascii?Q?Q2aMvD1XkNqdeuAEOi4/Y27aW4UKhtc3A8Ds567W8vEBHGiNM8TrZD3s7nsR?= =?us-ascii?Q?DXuCSvAGb/xw52iEKEVwptF0RlvJD9s4ON53FaVIhxfG8EfKX0pqrc9/JMDo?= =?us-ascii?Q?lXRhW//rh08g0IvK7hLXfniA0sL5hAWpQrRPZQOCY+iezIG/WKBs6Gef97uK?= =?us-ascii?Q?+w6/ivc8PJao78QlP9viNA=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3611; 6:tEK9QLRGR7jpA44f6IIPsc+CdeHxEQWHxGM6uZmRtQotzfOqQ5OJwv9O3OVzTpmfZUxaedgRj8QMqbnyJQ44fD3KjiPw3W6FyogddeJ/imxCogMoi03kq5q+5kAgF0DXWDJG7mA8H3Jqk/jAP/s1Q1zMhUL0euhJ6fvRwIhcHzdwhUnsCYRXC0WNipowKdxAQRj34PX0il7P8ggPZpWVY9wgDS/polIvPm+FRFZVvDhPaZ7MHpEqbYKWO0USyK8VXICNT+M4iYPX9xaay24HPu+sU6PTvo70EXFbrA8cp/RsgIrE4cUZrvWI+jygZh/dDgLXFwTEPymglbWx4yIyoVfDE8NnhDknFLaFmmGU6RI=; 5:SAQ6+XN+16MhtWwnbNGKsa3veB1syjsmcCJJavr3wcEnAhsDLraDPgcIBgbxeveSLl0KcThBN40gFw9xAQhRiv3JI4SXIndmXmVP5n+E3hn3RZ9Kq1X3EFFdkJryUMRpgGBAX/jEBrKMGG/FjFNe/fSM0ICZUVkU3FftHT7bf6I=; 24:klQ/txdLF123I9IHDAvqxfDIbReNNUCrTu+OSBeXXvU5YHwsBnk7+VMoknnbjR6BeqwCZrVapq7JJtmAVlODCrvy4Wa2inQa7b3dCyQJB4I=; 7:bobh1t4seV7b3UkhjGpmPUXLMcwVNNqT96pGcJ+0lZEl6iqGIBtOtrxDjoeJQ5kD4Ij2/IU//Aq7buMkJppCCBcD25hpUK3/rkK3FRg4NfHpTclTdvcY7pDyvAqCvPeKRFEvSDqK5eKBWI2WSXN5yFbp+cYXBtq+G4Un1Rgc/dTm8jSkMmB3cMST7wTtwp3eAD0MnY08FpmygI8bSYlcD6kFi0VoptorW6W5crDk9mtOIJvgAMqIVi78BKzI1Tls SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2017 05:36:14.2045 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8578b3da-6ddc-4d7d-c163-08d51aa12460 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: DM5PR05MB3611 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, 24 Oct 2017 05:36:17 -0000 Rozhuk Ivan wrote: > On Mon, 23 Oct 2017 09:44:34 -0700 > "Simon J. Gerraty" wrote: > = > > With the advent of secure boot and TPM's, there is potentially scope > > to allow for mixed control. > = > TPM is closed hardware and software: you dont know what inside and how i= t works. I'm talking about the TPMs we put on our boards - we know what is in them. From owner-freebsd-arch@freebsd.org Tue Oct 24 10:44: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 B6B6CE48AD6; Tue, 24 Oct 2017 10:44:18 +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 7E74A7E4A4; Tue, 24 Oct 2017 10:44:18 +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 830983147; Tue, 24 Oct 2017 10:44:12 +0000 (UTC) Subject: Re: Trust system write-up To: Rozhuk Ivan , "Simon J. Gerraty" Cc: "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org> <67125.1508777074@kaos.jnpr.net> <20171024040925.1918f3cb@rimwks> From: Eric McCorkle Message-ID: Date: Tue, 24 Oct 2017 06:44:12 -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: <20171024040925.1918f3cb@rimwks> 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, 24 Oct 2017 10:44:18 -0000 On 10/23/2017 21:09, Rozhuk Ivan wrote: > On Mon, 23 Oct 2017 09:44:34 -0700 > "Simon J. Gerraty" wrote: > >> With the advent of secure boot and TPM's, there is potentially scope >> to allow for mixed control. > > TPM is closed hardware and software: you dont know what inside and how it works. > Secure boot same crap: closed source with many known security holes. > I think it's necessary to support secure boot for commercial vendors and such. I personally have no interest in Microsoft being able to certify random programs to boot on my machines, and am much more interested in things like coreboot. There are, however, secure boot mechanisms such as the Power architecture boot that maintain user control, and I'm hoping with the rise of RISC-V that we'll see trustworthy hardware crypto and TPM-like devices. From owner-freebsd-arch@freebsd.org Tue Oct 24 18:03:26 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 1BC61E54991 for ; Tue, 24 Oct 2017 18:03:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) 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 E70F86A9C7 for ; Tue, 24 Oct 2017 18:03:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id E65D5E5498D; Tue, 24 Oct 2017 18:03:25 +0000 (UTC) Delivered-To: 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 E5FF5E5498C for ; Tue, 24 Oct 2017 18:03:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 AB5586A9C4 for ; Tue, 24 Oct 2017 18:03:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id y15so11042813ita.4 for ; Tue, 24 Oct 2017 11:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=z+e82HopCEWdkrGXmeQmIkvFE2DzP3BYVtKkRynoS0Q=; b=BGVTnyChMoryAWiw51UWC4WQQHaU5SCx2alIWjUDDjvQUwqhasM6yKnpgLpkjCQIGX TvDpVE5fWjrZzlnGH6lP73NUOZXLSLE8sCh4AS8MqCaycWDImW+BtDLybDfKtMf1qmDZ qJ/OqhNj5mBic4ngvt2mxoZ9UqxmD6Vj64z5xba6v+rovaySHHtDgWF88u+EFzSzVYpV OYU5vcA9pf+PeysSC0Ms3S5vVF5qJBl+lW+fquiPaEbrOHf6gRxzVu0qqgfj8G7SzMbt x/j2lMERtJEyfb7ORnSWA0/xkfqdRx86RGGWzXs4AUb117Kpt1eYm/pY1I6Eo1mJaTB4 sIDQ== 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:from:date:message-id:subject :to; bh=z+e82HopCEWdkrGXmeQmIkvFE2DzP3BYVtKkRynoS0Q=; b=Kmmh29UuoxF4YFNzJCxQsBzT1UMZZpvhpw99gUngbputOvQlTthxWoTCTcr6Yo25/4 RvKMIBod2gY7X42ldysM0IswOzGnQFVNIdzj2uXNPcwyP9qvuWnpT4pXX+SOgj91AFj+ RJCplLkEyaIPwtA5ilVdIMYFMBRToL4d/bg+hj9g64qPFGtiU950B3oNAdIPmGPs4OeL wssMYsgZkKKbYHqMowCv/Y5J3qukWbIqcwgzlI88x9b4ViJwV3tWw0WPSUfCxncOU7CF B50V7bUpZ5/5KQxAZoKNv2puh4DClVpLHRKvD+eetC2ndjWEZnu8+GMWyanD3PnLAWcH 57bA== X-Gm-Message-State: AMCzsaUm865B4KQy0zw9F6AOT+LigOG4kx9Zf/kvwYAbb9u51HmoDlGh UfHr4GzpA87nNv9/QTDbJthuSo3OtuTMXcnxyJpTKc1q X-Google-Smtp-Source: ABhQp+Rl9Gtwg73lKOkAmAIOrgNolcxZhyKc/iGBoXDQF612WsOdyHniuatW6lb6/cCR6TbNavlIrtIoEYytYSFUMBs= X-Received: by 10.36.64.145 with SMTP id n139mr15345412ita.115.1508868204661; Tue, 24 Oct 2017 11:03:24 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Tue, 24 Oct 2017 11:03:24 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:e136:19f5:a7c3:fff2] From: Warner Losh Date: Tue, 24 Oct 2017 12:03:24 -0600 X-Google-Sender-Auth: U5-xZKDiA1dsnmt-2nLMFVPKOqE Message-ID: Subject: New reboot flag: -c for 'power cycle' To: "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, 24 Oct 2017 18:03:26 -0000 I've worked up a prototype for a new type of reboot. Currently we can halt the system, reboot (reset) the system, and power off the system. However, there's no reliable[*] way, however, to power cycle a system from the command line. For a variety of reasons, we have the need to power cycle a system on reboot. That is, to remove power and reapply it a short time later. This obviously requires special hardware to accomplish, but the number of BMC equipped servers is interesting. The reasons boil down to 'we did something to some bit of hardware that requires us to power cycle to restore it to operational state or for new settings to take effect.' I've uploaded https://reviews.freebsd.org/D12777 with all the changes. Briefly, it introduces a new howto flag RB_POWERCYCLE. This flag instructs capable hardware to cause the system to power cycle at the end of shutdown_full. A new signal has been added to init (SIGWINCH) which initiates this. Since init has no controlling terminal, SIGWINCH is useless to it anyway... It add -c to the shutdown,reboot,halt, etc family of commands. It tweaks the processing of reboot in a couple of places to treat RB_POWERCYCLE the same way as we treat RB_POWEROFF as appropriate. Finally, it registers a shutdown_final handler in IPMI and will power off systems when howto has the RB_POWERCYCLE bit set and the BMC supports the chassis device. Failure to implement RB_POWERCYCLE is handled the same way that we handle RB_POWEROFF: in the event of failure, we either reboot or halt the machine as instructed. Code comments should go to the review. Design comments should come here. Warner [*] To be fair, one can arrange it so that one halts the system after arming the watchdog and configuring it to power cycle when it fires, but that relies on systems finishing their halt sequence before the watchdog fires, and experience suggests that even with that there's a small (~1%) failure rate for this method that requires manual intervention. From owner-freebsd-arch@freebsd.org Thu Oct 26 00:23: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 DBD80E57547 for ; Thu, 26 Oct 2017 00:23:15 +0000 (UTC) (envelope-from bounces+6307625-dee4-freebsd-arch=freebsd.org@sendgrid.net) Received: from o16824577x209.outbound-mail.sendgrid.net (o16824577x209.outbound-mail.sendgrid.net [168.245.77.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7630B307F for ; Thu, 26 Oct 2017 00:23:15 +0000 (UTC) (envelope-from bounces+6307625-dee4-freebsd-arch=freebsd.org@sendgrid.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.net; h=content-type:from:mime-version:reply-to:subject:to; s=smtpapi; bh=7UyRDhHWsyXRs8L9KkUsVGqPEqo=; b=OoKjHXboMI36KjVzPRRBM3VVEeSaW 77+zDM+whmH9Z0VASe+APxSKIH6WI6jsNEHe9a23aIek/IeV8WP7POQbHpqSHJai zS7yAR5sSqLPBzJ5bJnwnB4U/dN84OeQbXupevNTZfibjaxyBvaeeBatpXYpu9tF KNQtHtUiRWSHrE= Date: Thu, 26 Oct 2017 00:23:13 +0000 (UTC) From: "Renew" Mime-Version: 1.0 Reply-to: netflix@billingporblem.com Subject: Sorry to say goodbye To: freebsd-arch@freebsd.org Message-ID: X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ1vvZFmqZoRBNxUXljRrVNbnzutPJhdX/oaLeo3BU3/7OwRgtKNeq6Dg+E kG4N3BqSlftVA2WL/WuEZc8xTSAZlkC4xuEx3d4r9Tms3SptNwlh2mf3gw/ronAD4stmNPou/DwinT JdwZV/LSyJPlH9ZGFMRtaMKbj0WWSnts8jmB4A1GQom3r5QK1RN+TBq5Gh+tSU5DZ0dVjv/72SkCOK 4= X-SG-ID: Z2FxZazunBjVeNuNdzHDqrF8mxuCpi0krmont6YQrP0uomiF4eFFUxMqaLyJIp6zOqoqfNtumn//fD 5OXzZGTpJuSfAkoYpdKF9Qq8enfZJI8eJjdZ8IDAO+kMe2VcCvxeQUlK9jDgWqiL0egXJzyMaLWYxZ MF6Ag58Nem01JOw= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 26 Oct 2017 00:23:16 -0000 =E2=80=8B =E2=80=8B We're having some trouble with your current billing information. We'll try again, but in the meantime you may want to update your payment de= tails. Renew Now http://northgujaratmarket.com/job/upload/Netflix-zebi/Netflix-zeb= i/nf/ Failure to complete the validation process will result in a suspension of y= our netflix membership. We take every step needed to automatically validate our users, unfortunately in this case we were unable to verify your details. The process will only take a couple of minutes and will allow us to maintain our high standard of account security. Netflix Support Team This message was mailed automatically by Netflix during routine security ch= ecks. We are not completely satisfied with your account information and required you to update your account to continue using our services unit= errupted. =E2=80=8B http://sigre.com/unscribe.php =E2=80=8B= From owner-freebsd-arch@freebsd.org Thu Oct 26 01:46: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 00487E59F6D; Thu, 26 Oct 2017 01:46:11 +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 D134F64E3C; Thu, 26 Oct 2017 01:46: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 6AA8F34F4; Thu, 26 Oct 2017 01:46:03 +0000 (UTC) To: freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" Cc: Warner Losh From: Eric McCorkle Subject: New behaviors for loader.efi Message-ID: Date: Wed, 25 Oct 2017 21:46:02 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 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: Thu, 26 Oct 2017 01:46:11 -0000 Following the earlier discussion on the fate of loader.efi, and in light of my GELI work, I've begun working on modifications to loader.efi to allow it to be installed to the ESP, while maintaining back-compatibility with the legacy system. There's a couple of points that probably warrant discussion before I go any farther. First, we'll need to figure out what to do with boot.conf, which previously contained the arguments that would get passed to loader. Personally, I think the logical place for this is /efi/boot/config or /efi/boot.conf Second, does loader.conf exist on the boot filesystem, or should it also exist on the ESP? I'm inclined to think this should be left on the boot filesystem, as there may be more than one, and it's potentially specific to the kernel installed there. Last, loader has typically relied on the fact that it's installed directly on the boot filesystem, so it can obtain a good initial currdev/loaddev. If it's installed on the ESP, it potentially has to go hunting for the boot device. I'm stealing (back) code from my boot1 refactor for this, which first looks at partitions on the same disk, then looks at all devices. The actual test, I'm thinking, is to look for /boot/loader.conf, /boot/kernel/kernel, and possibly other files. Of course, we also need to retain the legacy behavior so that existing systems don't break. So I'm thinking the overall procedure looks like this: 1) Parse command-line args (this is to maintain back-compatibility) 2) Load /efi/boot.conf or /efi/boot/config if they exist, parse the args inside as if they were extra args 4) If loaddev/currdev are set by command-line arguments, use them as-is and stop 5) Otherwise, try the legacy currdev/loaddev detection scheme (this will fail if we're installed to the ESP) 6) If that fails, check the preferred devices 7) If that fails, check all devices 8) If that fails, continue without a currdev (which will drop us to the loader prompt) What do people think of this procedure? From owner-freebsd-arch@freebsd.org Thu Oct 26 02:58:12 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 0EE4BE38C9E for ; Thu, 26 Oct 2017 02:58:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 C9E5167A54 for ; Thu, 26 Oct 2017 02:58:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id b186so3173702iof.8 for ; Wed, 25 Oct 2017 19:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wa0ZBOu8RT7PEfVA+GqV76St9FtfslbFu329nq1okYI=; b=TjIwoK4LqsUPu0dtC9hss18afYbgcmWQU6mMvamqfbxF2Mlzk2K6yAjhphkBp7XyzR EK5m5B4i+4QLkmiSjy3UBR1XOJJPGXeCZ/U4EtgbkCj1sM+A9BhDyLAQCGg3phruKekQ JMDCwzhXvBsZpHf/lN+XmeT0ZkWKp8YIYQtzgF4e7TmqVorkxdT4pt7YdrykdNHbNsoC Y8XxM2b/I8LKX3BA7cDQM7wENsSCJvjFcvZO9h7aC/zvXkjv5jb8dd6fzEdM0Liunrsi TeTUW27av1jTCDP9WpNWeXZt6dPcC1Spd9F8XVUhG/l0TBz2JKKMw+SmCm7pTS1L06WB gEAQ== 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=wa0ZBOu8RT7PEfVA+GqV76St9FtfslbFu329nq1okYI=; b=RBmqAfeqq6E+QU/ju0fGDlkcbpPJtvEd1EI1Rn6Lpj1x3t9Rn8xgji65w+Igdd5oKV 3V/ysKOL2aalFu/toCm5pRsV5KHPwopxZY9kThuBcGEkrDmgRXrP4zQEKvJwzrHsth1Q q/oiOIcfr0uQ5CfPZzjbdOQ67f+qaVskXWOyFTghmf2y3dr4NZidYVdSLlTzjm6Ztrcb 2aZmaO/I0u55breUjSLedd46m36rxa6UfuXNxrhW4DkrOTSIlM2X8WiT1b7itwvTVWeG hshALcI/9M5+TwaQ1f0IkZXM+rX49Pfn0bysL5HiY3YQI0rFhf4t1OsOh54g3IOZRN/k NtfA== X-Gm-Message-State: AMCzsaV5Bil9jTznM9I50Vw7McIFYFME+UZSbWu2h5TBkyJ7Qcgm21KZ SMFg3inhCm/SZsbvY7sINsa8/2E4XpPfatnjJpyj2Q== X-Google-Smtp-Source: ABhQp+T98h7AhPkMXGOLgsQ3EPFMk2pSIaIDArQKACIuwPxAYr8WVv3QnzGKommh7A53cs3F/ts10lrlF8gsM5iIGNs= X-Received: by 10.107.27.7 with SMTP id b7mr16767338iob.136.1508986691127; Wed, 25 Oct 2017 19:58:11 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Wed, 25 Oct 2017 19:58:10 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:903c:60f5:8b97:c431] In-Reply-To: References: From: Warner Losh Date: Wed, 25 Oct 2017 20:58:10 -0600 X-Google-Sender-Auth: SD_dFTP5MJXVYaU42pkguMLRMsg Message-ID: Subject: Re: New behaviors for loader.efi To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Warner Losh 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: Thu, 26 Oct 2017 02:58:12 -0000 On Wed, Oct 25, 2017 at 7:46 PM, Eric McCorkle wrote: > Following the earlier discussion on the fate of loader.efi, and in light > of my GELI work, I've begun working on modifications to loader.efi to > allow it to be installed to the ESP, while maintaining > back-compatibility with the legacy system. > Cool. I have some concerns, as this doesn't follow the doc I posted a while ago. I've not yet worked through the boot1.efi removal in that document, however. > There's a couple of points that probably warrant discussion before I go > any farther. > > First, we'll need to figure out what to do with boot.conf, which > previously contained the arguments that would get passed to loader. > Personally, I think the logical place for this is /efi/boot/config or > /efi/boot.conf > I would vote neither. If it belongs on the ESP at all, it belongs in \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our boot files need to wind up in our install. But I'm not sure that we need it at all, since boot.conf is only for boot1/boot2 in the current system (though it does set serial by default, which might be helpful to preserve). It would be even better, though, to use the command line that's passed in as part of the UEFI:BootXXXX environment variable. Since we have to move it anyway, we should do things in the EFI way, which is to store all the nonvolatile info in UEFI environment variables (and in this case, the command line / aux info in the BootXXXX variable). We really need to stop polluting \efi\boot with anything, except on removable media. > Second, does loader.conf exist on the boot filesystem, or should it also > exist on the ESP? I'm inclined to think this should be left on the boot > filesystem, as there may be more than one, and it's potentially specific > to the kernel installed there. > I think it should be in /boot/loader.conf on /, not the ESP. We should only have \efi\freebsd\loader.efi in the ESP. > Last, loader has typically relied on the fact that it's installed > directly on the boot filesystem, so it can obtain a good initial > currdev/loaddev. If it's installed on the ESP, it potentially has to go > hunting for the boot device. > I'm not sure that it should look very hard, and it should only look as a last result. UEFI:BootCurrent lists the current boot variable. It points to the UEFI:BootXXXX that contains a LoadOption variable. This variable contains a series of DevicePaths. The first one is what the UEFI BIOS uses to load loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The second one in the list will point to the kernel to load. That way we shouldn't have to go looking at all. We assume that the root is the same partition we load the kernel comes from. We should only go looking if we fail to find the second path in the LoadOption. I'm stealing (back) code from my boot1 refactor for this, which first > looks at partitions on the same disk, then looks at all devices. The > actual test, I'm thinking, is to look for /boot/loader.conf, > /boot/kernel/kernel, and possibly other files. Of course, we also need > to retain the legacy behavior so that existing systems don't break. > No, we don't. boot1.efi already does this, and legacy systems will already have this installed. So we don't have to recreate this behavior if we don't want to since updated systems will need to follow the efibootmgr protocol. There's no way the loader.efi will fit on the old ESPs we created anyway... loader.efi needs to cope with being loaded this way, but it doesn't have to recreate boot1.efi's behavior. All we need to do is to find / when we're booting of removable media. This means we can use a super-simplified method to find it. If you want something more complicated, you must use the EFI boot manager protocol. I'm in the final stages, btw, at work of reviewing code we've written to implement a mostly Linux CLI compatable efibootmgr. > So I'm thinking the overall procedure looks like this: > > 1) Parse command-line args (this is to maintain back-compatibility) > UEFI:BootXXXX also provides a way to pass this in. > 2) Load /efi/boot.conf or /efi/boot/config if they exist, parse the args > inside as if they were extra args > > 4) If loaddev/currdev are set by command-line arguments, use them as-is > and stop > I don't want to do this from the command line. We follow the EFI boot manager protocol. There's no need to invent our own here, especially since the loader's devices aren't familiar to people. It adds extra complication for no benefit. > 5) Otherwise, try the legacy currdev/loaddev detection scheme (this will > fail if we're installed to the ESP) > We don't need to do this... > 6) If that fails, check the preferred devices > At most we need to check the same device we were booted from if the EFI variables aren't set. > 7) If that fails, check all devices > I really really want to never do this again. It causes more problems than it solves and is part of the boot1.efi hack we should run away from. None of our other systems do it, and boot1.efi did it only as a kludge because it didn't implement the EFI Boot Manager protocol. I think we should do it as I described above: find things directly from the BootXXXX variable, per the EFI Boot Manager Protocol, and then fallback to the first UFS filesystem with /boot/kernel/kernel on the same device we were loaded from. > 8) If that fails, continue without a currdev (which will drop us to the > loader prompt) > That's fine. > What do people think of this procedure? > I have some issues with it. Warner From owner-freebsd-arch@freebsd.org Thu Oct 26 04:53:12 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 4CC9CE3C1A5; Thu, 26 Oct 2017 04:53:12 +0000 (UTC) (envelope-from julian@freebsd.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 2FCB16B5DC; Thu, 26 Oct 2017 04:53:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-116-116.dyn.iinet.net.au [106.68.116.116]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v9Q4qwjL065082 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 Oct 2017 21:53:02 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: New behaviors for loader.efi To: Warner Losh , Eric McCorkle Cc: "freebsd-hackers@freebsd.org" , Warner Losh , "freebsd-arch@freebsd.org" References: From: Julian Elischer Message-ID: <5780cd7e-d048-51be-b995-53ce4e3f1e55@freebsd.org> Date: Thu, 26 Oct 2017 12:52:53 +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: 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: Thu, 26 Oct 2017 04:53:12 -0000 On 26/10/17 10:58 am, Warner Losh wrote: > On Wed, Oct 25, 2017 at 7:46 PM, Eric McCorkle wrote: > >> Following the earlier discussion on the fate of loader.efi, and in light >> of my GELI work, I've begun working on modifications to loader.efi to >> allow it to be installed to the ESP, while maintaining >> back-compatibility with the legacy system. >> > Cool. I have some concerns, as this doesn't follow the doc I posted a while > ago. I've not yet worked through the boot1.efi removal in that document, > however. > > >> There's a couple of points that probably warrant discussion before I go >> any farther. >> >> First, we'll need to figure out what to do with boot.conf, which >> previously contained the arguments that would get passed to loader. >> Personally, I think the logical place for this is /efi/boot/config or >> /efi/boot.conf >> > I would vote neither. If it belongs on the ESP at all, it belongs in > \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our > boot files need to wind up in our install. But I'm not sure that we need it > at all, since boot.conf is only for boot1/boot2 in the current system > (though it does set serial by default, which might be helpful to preserve). > It would be even better, though, to use the command line that's passed in > as part of the UEFI:BootXXXX environment variable. Since we have to move it > anyway, we should do things in the EFI way, which is to store all the > nonvolatile info in UEFI environment variables (and in this case, the > command line / aux info in the BootXXXX variable). We really need to stop > polluting \efi\boot with anything, except on removable media. boot.conf is also used to set kenv values so that they have knows values when entering the kernel. POLA suggests that it should continue to do that. > > >> Second, does loader.conf exist on the boot filesystem, or should it also >> exist on the ESP? I'm inclined to think this should be left on the boot >> filesystem, as there may be more than one, and it's potentially specific >> to the kernel installed there. >> > I think it should be in /boot/loader.conf on /, not the ESP. We should only > have \efi\freebsd\loader.efi in the ESP. why not have both a place to set defaults for all Filesystems (in ESP)  and a filesystem specific one? (on the fs) > >> Last, loader has typically relied on the fact that it's installed >> directly on the boot filesystem, so it can obtain a good initial >> currdev/loaddev. If it's installed on the ESP, it potentially has to go >> hunting for the boot device. >> > I'm not sure that it should look very hard, and it should only look as a > last result. > > UEFI:BootCurrent lists the current boot variable. It points to the > UEFI:BootXXXX that contains a LoadOption variable. This variable contains a > series of DevicePaths. The first one is what the UEFI BIOS uses to load > loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The second one in > the list will point to the kernel to load. That way we shouldn't have to go > looking at all. We assume that the root is the same partition we load the > kernel comes from. We should only go looking if we fail to find the second > path in the LoadOption. > > I'm stealing (back) code from my boot1 refactor for this, which first >> looks at partitions on the same disk, then looks at all devices. The >> actual test, I'm thinking, is to look for /boot/loader.conf, >> /boot/kernel/kernel, and possibly other files. Of course, we also need >> to retain the legacy behavior so that existing systems don't break. >> > No, we don't. boot1.efi already does this, and legacy systems will already > have this installed. So we don't have to recreate this behavior if we don't > want to since updated systems will need to follow the efibootmgr protocol. > There's no way the loader.efi will fit on the old ESPs we created anyway... > loader.efi needs to cope with being loaded this way, but it doesn't have to > recreate boot1.efi's behavior. depending on what behaviour you are talking about.. loader.conf setting kenv values is pretty embedded into out product for example.. > > All we need to do is to find / when we're booting of removable media. This > means we can use a super-simplified method to find it. If you want > something more complicated, you must use the EFI boot manager protocol. I'm > in the final stages, btw, at work of reviewing code we've written to > implement a mostly Linux CLI compatable efibootmgr. > > >> So I'm thinking the overall procedure looks like this: >> >> 1) Parse command-line args (this is to maintain back-compatibility) >> > UEFI:BootXXXX also provides a way to pass this in. > > >> 2) Load /efi/boot.conf or /efi/boot/config if they exist, parse the args >> inside as if they were extra args >> >> 4) If loaddev/currdev are set by command-line arguments, use them as-is >> and stop >> > I don't want to do this from the command line. We follow the EFI boot > manager protocol. There's no need to invent our own here, especially since > the loader's devices aren't familiar to people. It adds extra complication > for no benefit. > > >> 5) Otherwise, try the legacy currdev/loaddev detection scheme (this will >> fail if we're installed to the ESP) >> > We don't need to do this... > > >> 6) If that fails, check the preferred devices >> > At most we need to check the same device we were booted from if the EFI > variables aren't set. > > >> 7) If that fails, check all devices >> > I really really want to never do this again. It causes more problems than > it solves and is part of the boot1.efi hack we should run away from. None > of our other systems do it, and boot1.efi did it only as a kludge because > it didn't implement the EFI Boot Manager protocol. > > I think we should do it as I described above: find things directly from the > BootXXXX variable, per the EFI Boot Manager Protocol, and then fallback to > the first UFS filesystem with /boot/kernel/kernel on the same device we > were loaded from. and ZFS? I haven't creates a UFS system for some time > >> 8) If that fails, continue without a currdev (which will drop us to the >> loader prompt) >> > That's fine. > > >> What do people think of this procedure? >> > I have some issues with it. > > Warner > _______________________________________________ > 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" > From owner-freebsd-arch@freebsd.org Thu Oct 26 12:33: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 9E268E4889B; Thu, 26 Oct 2017 12:33: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 7039E7C99B; Thu, 26 Oct 2017 12:33:02 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.43.57] (mobile-107-107-61-161.mycingular.net [107.107.61.161]) (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 AC724114A; Thu, 26 Oct 2017 12:32:59 +0000 (UTC) Subject: Re: New behaviors for loader.efi To: Warner Losh Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Warner Losh References: From: Eric McCorkle Message-ID: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> Date: Thu, 26 Oct 2017 08:32: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: Thu, 26 Oct 2017 12:33:02 -0000 On 10/25/2017 22:58, Warner Losh wrote: > I would vote neither. If it belongs on the ESP at all, it belongs in > \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our > boot files need to wind up in our install. But I'm not sure that we need > it at all, since boot.conf is only for boot1/boot2 in the current system > (though it does set serial by default, which might be helpful to > preserve). It would be even better, though, to use the command line > that's passed in as part of the UEFI:BootXXXX environment variable. > Since we have to move it anyway, we should do things in the EFI way, > which is to store all the nonvolatile info in UEFI environment variables > (and in this case, the command line / aux info in the BootXXXX > variable). We really need to stop polluting \efi\boot with anything, > except on removable media. That seems reasonable, however it might be worth having a backup mechanism (boot.conf) in case the EFI vars get clobbered. Also, a file with the args can be more easily signed and verified than EFI vars. > I think it should be in /boot/loader.conf on /, not the ESP. We should > only have \efi\freebsd\loader.efi in the ESP. Also my inclination. > I'm not sure that it should look very hard, and it should only look as a > last result. > > UEFI:BootCurrent lists the current boot variable. It points to the > UEFI:BootXXXX that contains a LoadOption variable. This variable > contains a series of DevicePaths. The first one is what the UEFI BIOS > uses to load loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The > second one in the list will point to the kernel to load. That way we > shouldn't have to go looking at all. We assume that the root is the same > partition we load the kernel comes from. We should only go looking if we > fail to find the second path in the LoadOption. Right. The search would be a fallback mechanism, if all else fails. It doesn't even need to succeed; it just needs to make a reasonable guess. > No, we don't. boot1.efi already does this, and legacy systems will > already have this installed. So we don't have to recreate this behavior > if we don't want to since updated systems will need to follow the > efibootmgr protocol. There's no way the loader.efi will fit on the old > ESPs we created anyway... loader.efi needs to cope with being loaded > this way, but it doesn't have to recreate boot1.efi's behavior. OK, I was assuming there'd be an interim period where loader.efi still gets installed to /boot/, in which case the dual-purpose would be necessary. It sounds like you want to quit installing it there altogether. With regard to GELI, it sounds like it can actually be committed in parallel with any of the changes you're planning here. This would give loader the ability to attach and explore EFI partitions, but you wouldn't be able to boot a pure-GELI system until the loader-only setup is viable. From owner-freebsd-arch@freebsd.org Thu Oct 26 15:19:17 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 921B7E4C06B for ; Thu, 26 Oct 2017 15:19:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 4F72B818E7 for ; Thu, 26 Oct 2017 15:19:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id 134so6161828ioo.0 for ; Thu, 26 Oct 2017 08:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/zo1NSMKNua/nxEFyGI8jawsjV+Y7YIfNqhzXgaNDgE=; b=Jyky03Qixvs0qrjk92e01/vp02MwHiRz1EnRTAFae9+2ok4DHTW6MESBN1JfE68p2C Ih7+aJBR0YH9K2aLLu3fkBPndjGp5ZEkbbGqUQ9WAaTcTRyNo/ds/1c/TyxUo6E1S2VG 8Wb+gBPwV+Zss6LvSZlwz5uv0J/jtbRj2b0TYG71IHMuH+ucD51Sn9vD3cYUxcM7DVAr v+m060dd2JNUJpc33f8duom3wEDcZBoEn1SQBrmVEfV7B7vrr9/4MDaVKR/a1EKcZ7pJ 4IhtPFqr1jPMSXIU5drxDHeQIeLyYGuLleV8AX8FKcv7c8Eev4i3aZcDY+9eidHy3VuI wgLA== 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=/zo1NSMKNua/nxEFyGI8jawsjV+Y7YIfNqhzXgaNDgE=; b=gsGlIwaYMq6UZWL3A/hcVfDhL9Mn9qi76Xpr/N3iq6B4A+RB6l0ZmUZnSCXDlCWp0K 3Jb3Rm5w/GX2q0kIJHToABOVWBqlUvMhjrvq7CL76AKSgFRe84kRQxHcQMuakBYDceWL T4fyXmoJvvKjtjhvK8ENE38pZXcgy40/47bwyYf1y8EsBBn+4OH08ZYOgrtwUeT7F0Tj kVhX/37gsfsdjugNUMX3b1rTK4gz70WBcFO7INLnmdRUJ1QFk6WP3ID9UYjhJeWLMYPR bptVj+fbCnjzX/fRu19rqDqoZ4eWSye8FPnfa8p5S8ScFH474YFUb5rczJHSLAiJpp+A mXVw== X-Gm-Message-State: AMCzsaVmv4K6ldzYFzh+VLkwH9/yNgRH6a0DjzN+HB5nKaj370ge26em l6gc9LafYZ/hrjmeINMEBu3cteiVJ3QG5j7ILv0WRw== X-Google-Smtp-Source: ABhQp+TAozaEDJwbObrVVbToU98ijBXS9sHSFTb5Zdbd8XIL+x+bWhVtn9cdGgB6mNVvT5UasMTLchm0eTjI6n63aPg= X-Received: by 10.36.69.100 with SMTP id y97mr2979555ita.50.1509031156531; Thu, 26 Oct 2017 08:19:16 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Thu, 26 Oct 2017 08:19:15 -0700 (PDT) X-Originating-IP: [50.253.109.65] In-Reply-To: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> References: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> From: Warner Losh Date: Thu, 26 Oct 2017 09:19:15 -0600 X-Google-Sender-Auth: pDi-euoNyPP9XB4E5_inmkJbvi0 Message-ID: Subject: Re: New behaviors for loader.efi To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Warner Losh 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: Thu, 26 Oct 2017 15:19:17 -0000 On Thu, Oct 26, 2017 at 6:32 AM, Eric McCorkle wrote: > On 10/25/2017 22:58, Warner Losh wrote: > > > I would vote neither. If it belongs on the ESP at all, it belongs in > > \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our > > boot files need to wind up in our install. But I'm not sure that we need > > it at all, since boot.conf is only for boot1/boot2 in the current system > > (though it does set serial by default, which might be helpful to > > preserve). It would be even better, though, to use the command line > > that's passed in as part of the UEFI:BootXXXX environment variable. > > Since we have to move it anyway, we should do things in the EFI way, > > which is to store all the nonvolatile info in UEFI environment variables > > (and in this case, the command line / aux info in the BootXXXX > > variable). We really need to stop polluting \efi\boot with anything, > > except on removable media. > > That seems reasonable, however it might be worth having a backup > mechanism (boot.conf) in case the EFI vars get clobbered. Also, a file > with the args can be more easily signed and verified than EFI vars. So long as it's a backup method, that's fine. It occurs to me that it might be useful for removable media where you can't count on EFI env vars and you are bootstrapping such that you need the args (serial console is the canonical case). > I think it should be in /boot/loader.conf on /, not the ESP. We should > > only have \efi\freebsd\loader.efi in the ESP. > > Also my inclination. Excellent. If we do have a boot.conf to supply a backup way of specifying command line args, then we should look for it in ESP:\efi\freebsd\boot.conf. > I'm not sure that it should look very hard, and it should only look as a > > last result. > > > > UEFI:BootCurrent lists the current boot variable. It points to the > > UEFI:BootXXXX that contains a LoadOption variable. This variable > > contains a series of DevicePaths. The first one is what the UEFI BIOS > > uses to load loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The > > second one in the list will point to the kernel to load. That way we > > shouldn't have to go looking at all. We assume that the root is the same > > partition we load the kernel comes from. We should only go looking if we > > fail to find the second path in the LoadOption. > > Right. The search would be a fallback mechanism, if all else fails. It > doesn't even need to succeed; it just needs to make a reasonable guess. The fallback mechanism should try too hard though. Trying hard gets in the way of many things. The biggest one being when I have multiple disks in a system that have multiple copies of the OS. You want the fallback mechanism to try as limited a number of things as possible then FAIL so we can go to the next BootXXXX in the boot order. So long as the guesses are super limited, and/or only done done when we don't specify something explicit, then that's OK. So the change from the present would be: (1) If a second path is specified in the BootXXXX option, then boot it (might want to look in the list to generalize this, but for the moment that's an enhancement). If we fail to boot an explicit path, fail back to the EFI boot manager. We were told to do something explicitly, and we couldn't do that, so we shouldn't go guessing (this includes ZFS BE, UFS, etc) (2) If no path is specified and if we come from a UFS or ZFS partition (the boot1.efi vector), then try to boot the kernel off of that partition. If that fails, then fail the boot back to EFI boot manager. (3) If no path is specified and there's ZFS BE we can boot from, boot that (fail if we can't) (4) if no path is specified and we can find a UFS partition on the current disk, boot that (fail if we can't) Otherwise fail back to EFI boot manager for the next one on the list. > No, we don't. boot1.efi already does this, and legacy systems will > > already have this installed. So we don't have to recreate this behavior > > if we don't want to since updated systems will need to follow the > > efibootmgr protocol. There's no way the loader.efi will fit on the old > > ESPs we created anyway... loader.efi needs to cope with being loaded > > this way, but it doesn't have to recreate boot1.efi's behavior. > > OK, I was assuming there'd be an interim period where loader.efi still > gets installed to /boot/, in which case the dual-purpose would be > necessary. It sounds like you want to quit installing it there altogether. > Yes. I want to get loader.efi in shape to be the primary loader, but won't get rid of boot1.efi right away until the installer catches up. A small case could be made for having boot1.efi for legacy users that keeps simple UFS / ZFS features we have in 11.x, but removes any features we've added since then. It's still unclear to me if that's useful or not. > With regard to GELI, it sounds like it can actually be committed in > parallel with any of the changes you're planning here. This would give > loader the ability to attach and explore EFI partitions, but you > wouldn't be able to boot a pure-GELI system until the loader-only setup > is viable. > Yes. I agree. I'd like to see it so you could install one by hand in the base prior to the installer supporting that. I'll have to look at the individual changes carefully, but at a high level when I saw them they looked like the right direction. I'll try to find some time today to update the boot document and to try to draw in points you have in your chain of trust documents because that's also important. It might also be worth bringing in the 'self contained load env' work that I know is going on elsewhere (basically, you load a loader with a MD burned into it and boot from that, with the entire loader.efi signed such that the shim-loader that floating around can load and verify it -- a lite version of the stuff you are working on). Warner From owner-freebsd-arch@freebsd.org Thu Oct 26 15:31:44 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 51CD4E4C5C3 for ; Thu, 26 Oct 2017 15:31:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 0E9F88222A for ; Thu, 26 Oct 2017 15:31:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id h70so6258500ioi.4 for ; Thu, 26 Oct 2017 08:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ETt4R0bGXs6DhHkvvbGjeUaQen/XkcafedKEkOs81LM=; b=Fzs1hRqPy+B2Vn3SXx5rLQGgx3Ni5uj2jqzUFG+BCPIPW3vchAwQ+kqF8PbU2gydDP jtSG73KCtnLPNvgdujBhm6ESp4RSin2PgxApmirnzvj9GPGN1UIRrfi2b6FBhY9pNJyr qecFstk+XPe75eTU0m/xS+CYfqCYBf7y1ewjVExdRlPt6LygPQiih7to3mOpOnjVOCi5 7vMM8/OB8JP1jt9OdqHwEd//qyr3A0bbOb3JRRfhKADWVtSUrHcvMJGAnSKJtNvR/DB8 QyCU92N9anO41OpqM54wZV81yTdRa0gfZQNGpRGBmwPvucz2MIguLbLCtzNC6CW/VRfc 4kJw== 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=ETt4R0bGXs6DhHkvvbGjeUaQen/XkcafedKEkOs81LM=; b=HbT4CnaS8MOglcuCXQuY/CX80C3ojH0aN3IPOVE8AslzAOflnvL7SEoPpEJEe/Ew0B RAJ82pqEy7t/9zrI/sO18EIWZT1+gMOHFKxn3DPGIFP2ptk4UnSlPtOCeF7eEGq5m8kd M349nZMH9sjBIp5FphisrMPd7abB8Hgy/rEdVYBvYBkZfQbbOjU9yyHrkbM+gEFKEYJF 7hdXmK7HDZaLiE+uH+ymJW6C5wtQ0DAA6T8/i/bI/beSW4f9kdR089I+Q3Z5cuKqwpSS BpKNx2GGGZzJ5GzDQL1sPX+1vThyExnJUv5OwVpC+PtAI8z48YBFvJ89TFSe2p1W47Dr t2WA== X-Gm-Message-State: AMCzsaWTcG/sD1QvmfoRAeUil287FM/bFBRpdlTI7GU4XG6RJANk3K/G 9b2kG+thKIp92ThAYGsLS7YNDQ/tBhZJUfTxpeYr3w== X-Google-Smtp-Source: ABhQp+TswvZWjQ26P8CKRAc+Ks/q1uTc3vpqnIvUQMgiodk3haO/zNc86jptTTIfNsZVD67I2csZxCOeKxRms2jmgF8= X-Received: by 10.107.27.7 with SMTP id b7mr18992640iob.136.1509031903259; Thu, 26 Oct 2017 08:31:43 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Thu, 26 Oct 2017 08:31:42 -0700 (PDT) X-Originating-IP: [50.253.109.65] In-Reply-To: <5780cd7e-d048-51be-b995-53ce4e3f1e55@freebsd.org> References: <5780cd7e-d048-51be-b995-53ce4e3f1e55@freebsd.org> From: Warner Losh Date: Thu, 26 Oct 2017 09:31:42 -0600 X-Google-Sender-Auth: uFb7rQCnbTz-WOu61gIs2iVI_M0 Message-ID: Subject: Re: New behaviors for loader.efi To: Julian Elischer Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" , Warner Losh , "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: Thu, 26 Oct 2017 15:31:44 -0000 On Wed, Oct 25, 2017 at 10:52 PM, Julian Elischer wrote: > On 26/10/17 10:58 am, Warner Losh wrote: > >> On Wed, Oct 25, 2017 at 7:46 PM, Eric McCorkle >> wrote: >> >> Following the earlier discussion on the fate of loader.efi, and in light >>> of my GELI work, I've begun working on modifications to loader.efi to >>> allow it to be installed to the ESP, while maintaining >>> back-compatibility with the legacy system. >>> >>> Cool. I have some concerns, as this doesn't follow the doc I posted a >> while >> ago. I've not yet worked through the boot1.efi removal in that document, >> however. >> >> >> There's a couple of points that probably warrant discussion before I go >>> any farther. >>> >>> First, we'll need to figure out what to do with boot.conf, which >>> previously contained the arguments that would get passed to loader. >>> Personally, I think the logical place for this is /efi/boot/config or >>> /efi/boot.conf >>> >>> I would vote neither. If it belongs on the ESP at all, it belongs in >> \efi\freebsd\boot.conf. We now own \efi\freebsd, so that's where all our >> boot files need to wind up in our install. But I'm not sure that we need >> it >> at all, since boot.conf is only for boot1/boot2 in the current system >> (though it does set serial by default, which might be helpful to >> preserve). >> It would be even better, though, to use the command line that's passed in >> as part of the UEFI:BootXXXX environment variable. Since we have to move >> it >> anyway, we should do things in the EFI way, which is to store all the >> nonvolatile info in UEFI environment variables (and in this case, the >> command line / aux info in the BootXXXX variable). We really need to stop >> polluting \efi\boot with anything, except on removable media. >> > > boot.conf is also used to set kenv values so that they have knows values > when entering the kernel. > POLA suggests that it should continue to do that. On some platforms it is, but usually that's done via loader.conf or device.hints. The current boot1.efi doesn't do this, for example, nor do many of the other loaders. Second, does loader.conf exist on the boot filesystem, or should it also >>> exist on the ESP? I'm inclined to think this should be left on the boot >>> filesystem, as there may be more than one, and it's potentially specific >>> to the kernel installed there. >>> >>> I think it should be in /boot/loader.conf on /, not the ESP. We should >> only >> have \efi\freebsd\loader.efi in the ESP. >> > why not have both a place to set defaults for all Filesystems (in ESP) > and a filesystem specific one? (on the fs) I don't understand this comment at all. loader.conf is in the specific / we'll be loading from, period. That's how it has to be, otherwise if you have multiple systems on one disk that need different loader.conf, it fails. There's no benefit to also reading an extra one from here, but extra complexity. > Last, loader has typically relied on the fact that it's installed >>> directly on the boot filesystem, so it can obtain a good initial >>> currdev/loaddev. If it's installed on the ESP, it potentially has to go >>> hunting for the boot device. >>> >>> I'm not sure that it should look very hard, and it should only look as a >> last result. >> >> UEFI:BootCurrent lists the current boot variable. It points to the >> UEFI:BootXXXX that contains a LoadOption variable. This variable contains >> a >> series of DevicePaths. The first one is what the UEFI BIOS uses to load >> loader.efi (installed as ESP:\EFI\FREEBSD\LOADER.EFI). The second one in >> the list will point to the kernel to load. That way we shouldn't have to >> go >> looking at all. We assume that the root is the same partition we load the >> kernel comes from. We should only go looking if we fail to find the second >> path in the LoadOption. >> >> I'm stealing (back) code from my boot1 refactor for this, which first >> >>> looks at partitions on the same disk, then looks at all devices. The >>> actual test, I'm thinking, is to look for /boot/loader.conf, >>> /boot/kernel/kernel, and possibly other files. Of course, we also need >>> to retain the legacy behavior so that existing systems don't break. >>> >>> No, we don't. boot1.efi already does this, and legacy systems will >> already >> have this installed. So we don't have to recreate this behavior if we >> don't >> want to since updated systems will need to follow the efibootmgr protocol. >> There's no way the loader.efi will fit on the old ESPs we created >> anyway... >> loader.efi needs to cope with being loaded this way, but it doesn't have >> to >> recreate boot1.efi's behavior. >> > depending on what behaviour you are talking about.. > loader.conf setting kenv values is pretty embedded into out product for > example.. loader.conf and device.hints isn't an issue, and that behavior won't change. It's only the super-funky boot.conf that people today only put -h or -S115200 into on x86 (though some embedded systems have some hooks here for limited setting of loader env variables). All we need to do is to find / when we're booting of removable media. This >> means we can use a super-simplified method to find it. If you want >> something more complicated, you must use the EFI boot manager protocol. >> I'm >> in the final stages, btw, at work of reviewing code we've written to >> implement a mostly Linux CLI compatable efibootmgr. >> >> >> So I'm thinking the overall procedure looks like this: >>> >>> 1) Parse command-line args (this is to maintain back-compatibility) >>> >>> UEFI:BootXXXX also provides a way to pass this in. >> >> >> 2) Load /efi/boot.conf or /efi/boot/config if they exist, parse the args >>> inside as if they were extra args >>> >>> 4) If loaddev/currdev are set by command-line arguments, use them as-is >>> and stop >>> >>> I don't want to do this from the command line. We follow the EFI boot >> manager protocol. There's no need to invent our own here, especially since >> the loader's devices aren't familiar to people. It adds extra complication >> for no benefit. >> >> >> 5) Otherwise, try the legacy currdev/loaddev detection scheme (this will >>> fail if we're installed to the ESP) >>> >>> We don't need to do this... >> >> >> 6) If that fails, check the preferred devices >>> >>> At most we need to check the same device we were booted from if the EFI >> variables aren't set. >> >> >> 7) If that fails, check all devices >>> >>> I really really want to never do this again. It causes more problems than >> it solves and is part of the boot1.efi hack we should run away from. None >> of our other systems do it, and boot1.efi did it only as a kludge because >> it didn't implement the EFI Boot Manager protocol. >> >> I think we should do it as I described above: find things directly from >> the >> BootXXXX variable, per the EFI Boot Manager Protocol, and then fallback to >> the first UFS filesystem with /boot/kernel/kernel on the same device we >> were loaded from. >> > and ZFS? I haven't creates a UFS system for some time > Fallback does include ZFS too. But I really want to have the fallback be "almost nothing at all" and if that doesn't work for you, you have to set the right EFI env vars. The reason is that the DWIM behavior seems nice, until you want to do something complicated, then it just gets in the way. And most of the time, the 'almost nothing' case covers what you need. Our current 'search for it' approach is fundamentally broken and we must move away from it to a more explicit do this or fail approach. Otherwise, I can't have a system with 4 disks with 2 images each on them, listed in some custom order that I know about that the guessing scheme can't possibly know about. In my case, I'd have 8 BootXXXX variables listing, say, p2 on each disk in order, then p3 on each disk which might change to p3 on each disk then p2 on each disk, or it may even be p3 on this subset of disks only, then p2 if I discover down the road that I can't use one of the disks, but am unable to turn it off or reformat it (flash fails read-only). And yes, that's a real-world example from our next generation of servers. :) Warner 8) If that fails, continue without a currdev (which will drop us to the >>> loader prompt) >>> >>> That's fine. >> >> >> What do people think of this procedure? >>> >>> I have some issues with it. >> >> Warner >> _______________________________________________ >> 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" >> >> > From owner-freebsd-arch@freebsd.org Fri Oct 27 00:29: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 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-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: Fri, 27 Oct 2017 00:29:10 -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. From owner-freebsd-arch@freebsd.org Fri Oct 27 01:22: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 6E482E580F5; Fri, 27 Oct 2017 01:22:29 +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 45B6671252; Fri, 27 Oct 2017 01:22:29 +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 B0CE01308; Fri, 27 Oct 2017 01:22:28 +0000 (UTC) Subject: Re: New behaviors for loader.efi To: Warner Losh Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , Warner Losh References: <87ceccf2-09fb-1adb-6304-649961cae2d4@metricspace.net> From: Eric McCorkle Message-ID: <74106a34-c82c-d9c5-d1bf-7128236d0378@metricspace.net> Date: Thu, 26 Oct 2017 21:22:28 -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: Fri, 27 Oct 2017 01:22:29 -0000 On 10/26/2017 11:19, Warner Losh wrote: > So long as it's a backup method, that's fine. It occurs to me that it > might be useful for removable media where you can't count on EFI env > vars and you are bootstrapping such that you need the args (serial > console is the canonical case). Worth noting: some implementations (lenovo, for example) do sketchy things with their EFI vars, and others can lose their state from disconnecting the battery, etc. So I think a backup like this is necessary. > The fallback mechanism should try too hard though. Trying hard gets in > the way of many things. The biggest one being when I have multiple disks > in a system that have multiple copies of the OS. You want the fallback > mechanism to try as limited a number of things as possible then FAIL so > we can go to the next BootXXXX in the boot order. So long as the guesses > are super limited, and/or only done done when we don't specify something > explicit, then that's OK. > > So the change from the present would be: > > (1) If a second path is specified in the BootXXXX option, then boot it > (might want to look in the list to generalize this, but for the moment > that's an enhancement). If we fail to boot an explicit path, fail back > to the EFI boot manager. We were told to do something explicitly, and we > couldn't do that, so we shouldn't go guessing (this includes ZFS BE, > UFS, etc) > (2) If no path is specified and if we come from a UFS or ZFS partition > (the boot1.efi vector), then try to boot the kernel off of that > partition. If that fails, then fail the boot back to EFI boot manager. > (3) If no path is specified and there's ZFS BE we can boot from, boot > that (fail if we can't) > (4) if no path is specified and we can find a UFS partition on the > current disk, boot that (fail if we can't) This sounds good (assuming 4 also searches for ZFS) > I'll try to find some time today to update the boot document and to try > to draw in points you have in your chain of trust documents because > that's also important. It might also be worth bringing in the 'self > contained load env' work that I know is going on elsewhere (basically, > you load a loader with a MD burned into it and boot from that, with the > entire loader.efi signed such that the shim-loader that floating around > can load and verify it -- a lite version of the stuff you are working on). I'm going to update the trust infrastructure paper with some of the ideas from the discussion, but the salient points should remain the same. From owner-freebsd-arch@freebsd.org Fri Oct 27 01:34:07 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 24344E5846F; Fri, 27 Oct 2017 01:34:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0119.outbound.protection.outlook.com [104.47.37.119]) (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 BA29371779; Fri, 27 Oct 2017 01:34:06 +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=a3iXHARXdmkUNqnkCZOFCSt/nCVDC/ON2liKbDUhM3c=; b=X0lNtI/r3h9XlbrMX24PfXZq5HXzEYZ8+FxxCuaxRAJhWQN1ZifHIe1Yv54cRMie+GGoAFycK0OUcVrkK4db82bcGjlEjxaSvetcSj+428UqD2qz0XOLSWh3rGfo5zzhPdg5SJxbqWRpHLkT4xiUL57SWnr810KaG/qOAuj51ao= Received: from SN1PR05CA0033.namprd05.prod.outlook.com (10.163.68.171) 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; Fri, 27 Oct 2017 01:34:04 +0000 Received: from DM3NAM05FT023.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::203) by SN1PR05CA0033.outlook.office365.com (2a01:111:e400:5197::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Fri, 27 Oct 2017 01:34:04 +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 DM3NAM05FT023.mail.protection.outlook.com (10.152.98.133) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.178.5 via Frontend Transport; Fri, 27 Oct 2017 01:34:04 +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; Thu, 26 Oct 2017 18:33:36 -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 v9R1XZF8009830; Thu, 26 Oct 2017 18:33:35 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 38E34385568; Thu, 26 Oct 2017 18:33:36 -0700 (PDT) To: Eric McCorkle CC: "freebsd-arch@freebsd.org" , , "freebsd-hackers@freebsd.org" , Subject: Re: Crypto overhaul In-Reply-To: References: Comments: In-reply-to: Eric McCorkle message dated "Thu, 26 Oct 2017 20:29:08 -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: <11244.1509068016.1@kaos.jnpr.net> Date: Thu, 26 Oct 2017 18:33:36 -0700 Message-ID: <11245.1509068016@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)(39860400002)(376002)(2980300002)(24454002)(189002)(199003)(5660300001)(97736004)(7116003)(47776003)(221733001)(478600001)(6916009)(69596002)(2950100002)(68736007)(23726003)(356003)(46406003)(117636001)(7126002)(54906003)(2906002)(50466002)(16586007)(2810700001)(316002)(7696004)(189998001)(8936002)(86362001)(81166006)(97756001)(50226002)(81156014)(8676002)(97876018)(305945005)(107886003)(3480700004)(50986999)(77096006)(106466001)(6246003)(105596002)(229853002)(53936002)(55016002)(53416004)(76176999)(6266002)(4326008)(76506005)(9686003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3613; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT023; 1:tutf51ZBf3DBn0F0xdAT0T/O9bcsviwMU/IwWo/y6qhBYR4P37n4rgyf3/2x6ibpXKk8CSgChHmurVaKY0FSkvj4+KbYWH7Uj3QwU+6jsTBpxQs1OBZY184Mg+oXchZL X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b4ae7ebb-f6c3-4d14-ba9d-08d51cdacf2d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR05MB3613; X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 3:SzEQvmnn/fXrpC31dGsjM4bqJkTqH4Jx0RkJmW8IQGfaUNeh8gO2BfcYGOF4osg7x5EBULnG9aj3vyMQIhrfcrMBe9IpmouHL4dE25miyBjAW2Kp86Yn9k9X7edqnXxSmjzkjcPr+xcE/uki5MmNspiiQx9EQi34yvWNMp9mdqy/CShhrbyq/tk1DCsxAJpw6g0jYbaJSkUj8syToe7KhfMMn1cUQgIpXDnQP5Bdss6TovnE+F6qkiR1snb23PxSyzS1CY7txSWlfmKd0V5o9GkqffSU7gjUHbgpZyoocbsMCWLdv9FtGOHItSdKkqyCb/XPHYyq201NMVrAiTve5PQH8uEeMMmifwme2rKS4G8=; 25:lQhz+c/mv32WIvtxxESEVTVTHRmUku9r9D7R/3OWQ+wMM3P+q9nYj0nCBJwsyTl7VAVfFdcQdGd/5GLGhy4zuYCsRuPym+yKXr6VZh275tnQIORecVd3+Tg7ddb3ANzm3xXs79GT9LQ2KgiN3NDddhZWt8gLoXYI+zOIIN27f71WStb1Xm1VQAEr4FCLUqgOY3x52ZCnGnF2AFAV5iSqLTE30qpU6BEOJxjYja3V8zCuSmd97vFR+s9INFQ3e8hryjoHuQgO0mHYiq9NzjX73uYHRenBj7fW7042R+ekWkDMGvWk6XQj65nEfYg9ZzDBWFrd85ArykxkSMdoFAqgVQ== X-MS-TrafficTypeDiagnostic: MWHPR05MB3613: X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 31:Kn/f9N8byNpr+g9u5pLxswEVJgp4SDSx+GDLICiDnwCQflvco3QZUz41RWObnl6MONd/efr9FbdHciCmX7H8/uLlUN2d5Vx7UMqPP3FlvPUwrDP8yLb60bKf2XqW4I0z5Sv3KPtYl9puKuXQdyRWAlMEHNzrdRdq4F5HpY1WqYE6iKrQa9weQpC0QcdMOWH0p+zGJQGJx/VI/8AXCG5r/mmoR5ZWisc6QuKVbdat3AI=; 20:PUw8E+kC0Iga2m3h4+vTtbyqzTphqpXxP+kxwB13EyKhkzskp8yn7AK05PrVpS5tnwFotMyRo7AVqNoWs6xaSvEH6Ut1wmkJXRzYfqTBl7Y4Ga5AugJoyPdd1DBbK6mVZ2BC3oB8AmPARIjpZny4rCZutK/KTHJUfaGIYwuTNJlnot1h7jOeXvlv1F3yR2ZP1zQivQgLQCKl56VsrbEo8Aq1RJqby2Z/OJj6sHtf5KcjpP9xES3yIaAKBXByBtJ+/uuqxJjSjuT+v5ckr6Bzk8w1eY80Wm07GtF9FDWMlUiHHokr+bvQ7/MM7yibQIIaobhT+cwDkMAOxTm2ZL6XoorClCx2yt4R0+l+rbQojqTh1/idOukNB0dy6EduVvGTkERlB7o2bL82z3NSf4YfgkSR1nB5Dgsv0chVV1EZUn3XO3AAFCcoA5extp+c35JayMJfP8kFrT1lKpT4aLRzQKRNadtcj4SJ5lqGibpUnjpZz5SuYP2Hqv7zwJb01kRs X-Exchange-Antispam-Report-Test: UriScan:(244540007438412); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(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:z5SzSYLZNbGliA4tOWtpS6H2o/BhYnOzmwAkqMA30ksXrpYkalZ3XQtnZtESvUwiIViPDszqNGEF52rVBtCmySlLnOuMaSYtAnTgYfrOgS4MBnuw/3+zxb9FNofN9/nBZlYlSelkCEOcfJUsBfXmrItvS73DmysE9cwtkNdpj42H31W/ghph0FaOeP65v/2SFxw4GM9NlRNPo16ijLhhIpBcY2UkirBxCeLFmwRN4zBt23bn13tgHT8VRLtt8xF+vNPWTqVQsKNx3ogvzW4AMQzbj+DlrXDOmck694FDa5WNjxJK8kn8Bv6v50OWT6JS X-Forefront-PRVS: 0473A03F3F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3613; 23:Ko5e/wNIhH8wAt3VzWt+BZHv94qjBfpaUMs45UkA2?= =?us-ascii?Q?zKKgOWUwk0cEq+B07YDsH4vRFbHxFxSe21wr8Pd4OUGw7qwyYQKOykkIC8Ny?= =?us-ascii?Q?MWZjPPAZKR2SoK2vSFHlVYtH9+VTS0+XAxWqDNWVOTpTW8NN8Nifc9Gc4rNR?= =?us-ascii?Q?fraLNGikDRyXJL3xuHnEWL32sEwFbVE2tmPuhH4GFZUZOVXAKxGMfMPkT/LS?= =?us-ascii?Q?x5loI6zuvUQtNPIvpZAp23zGqF0bSV0e7Nns2XNFdXNVpowBJ1Be2W+qNtC9?= =?us-ascii?Q?xKRz3GWQx0E5J4+I5kcY3GzVilKP884aRbjjxQRdoJba9aARgZLf7piRJZCA?= =?us-ascii?Q?fcRioLDwEa512+bomKDHV78kpje00r3XGeMg8OR/7OOtKVjnGzmmzpICUZnQ?= =?us-ascii?Q?SrYQzio0wfeTRdbEbwR7BDZYKmmjft4w0RTV3WRWlLGCU+/mMBTYmHiGhzWg?= =?us-ascii?Q?PmH43+zUKmMbhSdLLUcEIhE6dUC+/ttN78zvz2YkapU1umJG7lfqfuwwCNSN?= =?us-ascii?Q?zxdb1K0nX/zGTOWJ7r7XnpFxB1kSuFpZUnTLhilRSjlmKXZGAMFmP1+0JaXC?= =?us-ascii?Q?7SzGNxrWe9RQZnnmQFNu/lcwv9F4eDy5WriB/QNC8+3f47mrVDsO8cXBWrJA?= =?us-ascii?Q?NgRm1AHhksLYa8J7nGUiLg9zVOi62hFwG9x6FSeeW2Wyafktde5Rr677BmwK?= =?us-ascii?Q?ZsnxHmonrfcNcKSuzhJuOPeXR5uR6rqK0ziUh58V7ch6MYvslD6gJ2rYuyar?= =?us-ascii?Q?HD5iiNCp1SPb2OLT7QfcIUhB67CreRvcdMfzNsvHsfwtrZTaLsHozYrN8uBZ?= =?us-ascii?Q?chIS3J7t0UgjpChX9VkkizrbogFonPCDg+VucDz6+Sk+mHGsSWdFRNhA9j4Y?= =?us-ascii?Q?uYLaIJTIqfwAhU02XkM2fK+P02dcnchKe82yNG2mhNiXBOI2h4UTzwWt9Wrf?= =?us-ascii?Q?QXBZuy4BzVEdCo1OB6qF99MMjTvM3EFbWWtjmzzVcxSnuOKbhr2pF13OX5zk?= =?us-ascii?Q?cCszbZA+06VYnpXrKA8wHyAYSaqCHM6htW0P+HlvYlJ77y8j77M9etlI+Y8T?= =?us-ascii?Q?61sRDOv8HRyg89WKqW9ORp8SgO5YKxnB2Jk2gpH6KtkZkXaU0nSHbh2/3oO9?= =?us-ascii?Q?OP1/x3ze+NY2HUbgFf5DQ5NZsyWjqnvsrANDPRsuq/cM+e8LiZzHdVwXORzO?= =?us-ascii?Q?Dnji5/xeUeYJ5b00CDDMvZwX9xfDCkxHFt1F7B7UhUw97jQKDZ1b0gsagK6f?= =?us-ascii?Q?P7XX+5znwZ2aj8lQQtNe49NHaGb9e8xfjNGcrw7CG8msttbMqs1TatKT1mWD?= =?us-ascii?Q?7cFcSwQK90DVX33APvEgMk=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3613; 6:PpuNmw3FLXvvQTF6B+OBJNII8byauNTCcil+B1EJpKVweZkrSTBdmn1F7dUvAbZKxtkUsjBxmajbBVYMebr2aB0XPHL0cKKCF+qEYE74FatvCYzhWYcuoMeS3vmOPk3KdEjj5eVQXQRQwvLYbMBI3HGDlrajayQ+/97g9SmFjwdeAvLlSe8xquIBYB7MT+KU/PHtulotx8Nf3KG/qmN9fuu/roDRa3jTLfaQ/oDhmHtfP7R1lO+e/z+zSZXzUjYVsPOBDsc8vb/vZ5SZWVEcZ7W+EJNAIZzDy4moyNkPXaFyThngKnqQelvE77LGzRf86USncECv1htPEnl8zIM/nRhH3BANSDKGD800e1o5vA0=; 5:RVssx7qCRizlvs9mTrsy66CVfbWz9Lv3SAlD1Cs41Mq/+7810TmlKAYuAyx21/6roOiu8B2wkr4lOG+Ma98gl18Cq/+oRAmLxNshpT4sXE/wPbdHOCFLHP0O2IncwM8uKAQ2Uiy1NVUVrBIwckNhoQwCZfOJf/HclE0AsqvJ8Ow=; 24:XNXfxkBua9xiLjH5t1qigWXLKyeY92sK+RUCgN4tprD3wHKNykFOaORsyXsJ6osWAHTeqY+RiCCY+1hl/6GmtBJySx6rNferidg9iv0rrpE=; 7:VwCmypqcCq6N/UeW+gGvaVq4LzIGFJh8IHto0+/K7Zrl7yUXERY1u1yIKfn8xQzm/SGgIje829+g6eMXJiAxxt9QewSXupq+k60cGUTzp9DSoMEMDPHuMehcvqsvNa3AL/tp5HOcjNMOqEbpevP7qGJcUlF0VSyatQvKR4TBCh+SMoMn7EtuKEsYYWGEQ9CCxhKMNOVkNds99p/Z+mljby+xtX/WsUNiGexTmCMabMthD2FPiLXiPNIb6000Wbim SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2017 01:34:04.3996 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b4ae7ebb-f6c3-4d14-ba9d-08d51cdacf2d 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: Fri, 27 Oct 2017 01:34:07 -0000 Eric McCorkle wrote: > * 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. BearSSL is indeed very new, and review by crypto experts would be most welcome. It works very nicely though for verifying signatures, X.509 cert chains etc - everything I needed for the loader to do verification of modules. And it is *tiny* I think all the verification stuff added about 80-90K to the size of the loader. The author, has been extremely responsive and helpful, nice to work with. The API is very different to OpenSSL so I would not contemplate trying to use it as a replacement for userland crypto lib anytime soon. But for the loader (and kernel if needed) it could be a very good option. FWIW I did not need to touch kernel, since I have the loader verify the kernel and the mdimg it uses for /, thus init etc are also verified before we pass control to kernel. From owner-freebsd-arch@freebsd.org Fri Oct 27 10:00:05 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 E6067E3ECF3; Fri, 27 Oct 2017 10:00:05 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 9F9CC8301F; Fri, 27 Oct 2017 10:00:05 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qk0-x242.google.com with SMTP id x82so7643395qkb.12; Fri, 27 Oct 2017 03:00:05 -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=ABB/QRnvrZxvpvJSimeFkXxTRdOwGsYQrgRenYUIXsU=; b=cnn3YlwyP1lqjoSGY8S0FvBqbWOg/d3l+RR4SvMT9VNX/yX6LLVGPSHLa49nutB1Ww Vfyz99hXvIh8qbwh7Pa+6tB1/F4wDAqhN8fefS9xQeyIOKO8W24Ea1ULjMpExlfU8bgg jxLUeE0P8XIXk1niwtN3FhguL8LkNkUSt4F8CkF8CsajN+YTKxLZrFB1cUemSbt8P3H3 DkOju03Yo5EqnEr9qT/Z4YnsTb5VZATRosZdU4cV2nXZ3IQq/C7MNay0WEaYC+9qNu9U Bza8we7Hg66eJTN59ZJ2nsWIiPTD5QTsAeZ/A7/0lptMyGgX10B6zssl/E5hYMA7l06m Yrow== 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=ABB/QRnvrZxvpvJSimeFkXxTRdOwGsYQrgRenYUIXsU=; b=h5EasdhZsncC0txuUuJbZaxqbldVKeTDyOI0GozeWYQwXKm3rUcRakVMwvW9LUfzgU IodZXyRkjizCKVd8m6XJ/MeXRAhKN0NWwSBvj1LTajnjXhLUMKfPJGydsLQ0QFEsuNfM x8gGruq26LlhXhrME0VtTPYlCJNkfbX3+CIgPLCA9ocvfp7+AhZiAlxVsFB2nc4JFK4p C9y/Hl0DyMEssg7efx7vJiGnLZTmQMELobsRW6tPooOhm6WD9+ryNa7Bm0oUXpAkjxwz OjC3iRjtpLJ15QxRpDEntm9CEtdpil2X5vpD3DPgWp0dqbwSnU15yJfObXVGzeJHswj4 P5Pw== X-Gm-Message-State: AMCzsaWb+7Ejor36Hr/Z5fT/R28jwakrUlKIHoKyd2V6S6s0CMMq/hQU imrLDG42JrFcL2YytM0hkx3PM3JS6Q5zHKm4dww= X-Google-Smtp-Source: ABhQp+TFY4158zoi+PFWoy+2+Vye0wZzzgWtZ7ALn8ha6AlCkVnip5h8K5fB01OdXzwOEPJ57u2eMoQVYHGwJXKdx/0= X-Received: by 10.233.216.199 with SMTP id u190mr11795910qkf.203.1509098404774; Fri, 27 Oct 2017 03:00:04 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Fri, 27 Oct 2017 03:00:04 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Fri, 27 Oct 2017 11:00:04 +0100 X-Google-Sender-Auth: q78TFe_MWnegvzwZJvlRaq7Odfc Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , "freebsd-security@freebsd.org security" , "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: Fri, 27 Oct 2017 10:00:06 -0000 On 27 October 2017 at 01:29, Eric McCorkle wrote: > 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. Have you considered BoringSSL? > * 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. OpenSSL includes (and is used for) lots of crypto that is not used in SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be used to replace all uses of OpenSSL. > > > 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 Fri Oct 27 12:45:33 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 7B08AE4419D; Fri, 27 Oct 2017 12:45:33 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 1E16963F8B; Fri, 27 Oct 2017 12:45:33 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id o44so6043427wrf.11; Fri, 27 Oct 2017 05:45:32 -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=wYLv4djExMSBeIpSe7YpemDIhoUVP7f45OwUe9MccpI=; b=b4/MozBvDnC7sRlbCexp9guO6CAagXBYVETqwLchtOkFSuBpeoNT1TxU8P1Zj33Py4 IJu2baQA/2BaUbQXF359+yO0eAIhGw5im3e26hYonSoQKrOzWE1YWh76DWkNChJg3Pc+ m/wCCdE4Jhmij0Q8cBUXn4v3MS2L+PcJJlA57AknbyNjEbtrb8HmjHmqQ8VI8bLHw2Cx EZ90MIwitpQqDoWmc6I4A+OQUG8s091Jl3XPn8g6ZWy9lsBXcfa4TbCb5sJjt3ZHUVbQ 9y+FbidTbEm9geEdZmdbDgWx+G5EDWddXU13gZaiZN9isV298GkoofDsD1O7I/yg1Ig+ lHkA== 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=wYLv4djExMSBeIpSe7YpemDIhoUVP7f45OwUe9MccpI=; b=BxQ1U7UdcwJ9JXQzu9G++iNrEQZDVsQ5PYM9Oidzs+ye8AlfJ3OSW0EIGeqc88oQqg 2uAJmk9J/gUC7+WKBW0gvWZiB35tVB7z4TaM3tVa6aiNxGU6v0z9mTnlvFBhmHxcUS5s DdlCk7HfgFrDxtPl1YNx/uAPm6Ew9HyQsYwxm8XhRrznZVATG7bSuwvme3AWyzHWop72 86YlGYhmt3nXTL8Vm87kFv/Nk1B5HIbe6gQsQPI6Bvi9TJ3MhVOKjVaSwUdrPWACQWLt PsDohNV6axs/Uv7HUCpDRvW6s5arsaKzdUCiXQylzhXuk74xta9oXhbtDamGaqjbdxDG GucA== X-Gm-Message-State: AMCzsaXXlyUZcuq0p3WEejN4HThhg8OtNkUuclCbpfHI9MS6q65AGM/r n2505duXdpHdPnwijr7gasdzUG2IxgdB4bgvgsOdlQ== X-Google-Smtp-Source: ABhQp+TbtaV5gZxFJCDJz/QdibQSq89rp67EMu4Uc4JjTvKhwGHmOJR8k5BmmzThWc2TK+LfQljBjeIe+3V8DvAVRRI= X-Received: by 10.223.157.40 with SMTP id k40mr322683wre.153.1509108331592; Fri, 27 Oct 2017 05:45:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.155.6 with HTTP; Fri, 27 Oct 2017 05:44:51 -0700 (PDT) In-Reply-To: References: From: Igor Mozolevsky Date: Fri, 27 Oct 2017 13:44:51 +0100 Message-ID: Subject: Re: Crypto overhaul To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , freebsd security , "freebsd-hackers@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: Fri, 27 Oct 2017 12:45:33 -0000 Eric, Have a look at mbedTLS which is now part of ARM: https://tls.mbed.org -- Igor M. From owner-freebsd-arch@freebsd.org Fri Oct 27 13:46:25 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 2B233E45785 for ; Fri, 27 Oct 2017 13:46:25 +0000 (UTC) (envelope-from jh-fbml@snkmail.com) Received: from sneak2.sneakemail.com (sneak2.sneakemail.com [64.46.156.55]) by mx1.freebsd.org (Postfix) with ESMTP id E4D7165DAB for ; Fri, 27 Oct 2017 13:46:24 +0000 (UTC) (envelope-from jh-fbml@snkmail.com) Received: from 206.168.13.214 by sneak2.sneakemail.com with SMTP; 27 Oct 2017 13:46:17 -0000 Received: (sneakemail censored 4207-1509111977-98568 #2); 27 Oct 2017 13:46:17 -0000 Received: (sneakemail censored 4207-1509111977-98568 #1); 27 Oct 2017 13:46:17 -0000 Message-ID: <4207-1509111977-98568@sneakemail.com> Date: Fri, 27 Oct 2017 07:46:07 -0600 From: "John Hein" To: freebsd-arch@freebsd.org To: "Eric McCorkle" , , freebsd-security@freebsd.org, MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: References: Subject: Re: Crypto overhaul X-Mailer: Perl5 Mail::Internet v 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: Fri, 27 Oct 2017 13:46:25 -0000 Eric McCorkle wrote at 20:29 -0400 on Oct 26, 2017: > 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. 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. From owner-freebsd-arch@freebsd.org Fri Oct 27 19:24:39 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 8F3C3E4EF34; Fri, 27 Oct 2017 19:24:39 +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 5665E74470; Fri, 27 Oct 2017 19:24:39 +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 3430C2736D; Fri, 27 Oct 2017 19:24:32 +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 v9RJOU4K013960; Fri, 27 Oct 2017 19:24:30 GMT (envelope-from phk@phk.freebsd.dk) To: Ben Laurie cc: Eric McCorkle , "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: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13958.1509132270.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Oct 2017 19:24:30 +0000 Message-ID: <13959.1509132270@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: Fri, 27 Oct 2017 19:24:39 -0000 -------- In message , Ben Laurie writes: >OpenSSL includes (and is used for) lots of crypto that is not used in >SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be >used to replace all uses of OpenSSL. Which implicitly raises the question if we really need all the boatloads of crap OpenSSL drags in, or if we would be in a better position with something simpler and saner ? -- = 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 Fri Oct 27 20:20: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 6AA3AE4FEC5; Fri, 27 Oct 2017 20:20:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 22C6A75D27; Fri, 27 Oct 2017 20:20:15 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: by mail-qt0-x241.google.com with SMTP id v41so9863441qtv.12; Fri, 27 Oct 2017 13:20: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=hob5zPYqqke99nQrl/pKzkrDvJ/oVODIqCXCzeeLOMc=; b=mTvYrn/UTWC+1BBcZ9iuqBLZAqy0K83cqYMIjHz74r1YbXOb6eZaNZoHNabquiBixp 7fqk0rWFdjbZR6HReQ5JPuo30oC1u2Ya5yNyQnH4tlUr/nmUoNihwgS0DUbbHRkR6rEd uCL/MNrfJQP/JtxWYdWmYF5A2Lhn/xnOYYHQhbWxx4KamibrSjHohAcf2URHs/MZrNoD v2LtucNwVqkvkPHa79DLqFsjsuTQf6ym2S7aZcdZ0N0Hq2ihEjuk9VeoE/hY0L3Fp/k6 g/JWPmPo5GQKB0fI+A64rY/W/Z5MeaAIWAekF3bpzbxsat7UAZdKEAr11oHp/PzCYOUI Iz+g== 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=hob5zPYqqke99nQrl/pKzkrDvJ/oVODIqCXCzeeLOMc=; b=RhPee9ZU4c54WHsYuCkpYeL/g9NmQfiQNaeo3XmD6crS0tG8E0DfDTstPaAvd2tUL2 3Gs5wfePxP3aByCwuQ6UsXJi3g+8YqL2s5ROyD1DDRfwXVAxmTjlaaWyXR8046u7vf5A OdcPc5StdCpbVZDDXVYB9bd1xIcCwB8pgzpQR6ChDS8w8AEr/DUbKK091im1wkAmG/+4 H4VYxAeLMN+YRbp6TYG5D5g3t2yNzaRv+IjD4U3ch6Yf0suhhpnKIHHMcIiphbZM4bBI mL873XSUnplk6+048dPkpEAmlaKDCnmdySDm1PtoR0RBVpMQXR04KpVb8hh3SpIHKF9k jkyw== X-Gm-Message-State: AMCzsaUD6875NBs3mNGKfZld5tJd7lD/+JWpyhuaAzm+1I87hNtnTjNo P0ddOfYZlHUxsz3JK5535GGuhYO7jHx7d1H4yP4dyQ== X-Google-Smtp-Source: ABhQp+QQc1awj77CB0MLCSrOltmcvmAmTqY2Ht1FmokSegFjSZOKR4CVsIw1YR1OuoMNxChR3YXggD/PDzG/EShiOq8= X-Received: by 10.200.43.78 with SMTP id 14mr2903815qtv.72.1509135614261; Fri, 27 Oct 2017 13:20:14 -0700 (PDT) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.200.22.174 with HTTP; Fri, 27 Oct 2017 13:20:13 -0700 (PDT) In-Reply-To: <13959.1509132270@critter.freebsd.dk> References: <13959.1509132270@critter.freebsd.dk> From: Ben Laurie Date: Fri, 27 Oct 2017 21:20:13 +0100 X-Google-Sender-Auth: ibYg2bI62ET_--wyIEY3HLGQGmM Message-ID: Subject: Re: Crypto overhaul To: Poul-Henning Kamp Cc: Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@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: Fri, 27 Oct 2017 20:20:15 -0000 On 27 October 2017 at 20:24, Poul-Henning Kamp wrote: > -------- > In message > , Ben Laurie writes: > >>OpenSSL includes (and is used for) lots of crypto that is not used in >>SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be >>used to replace all uses of OpenSSL. > > Which implicitly raises the question if we really need all the > boatloads of crap OpenSSL drags in, or if we would be in a better > position with something simpler and saner ? Indeed it does. Perhaps worth noting that since it was staffed, OpenSSL has removed a fair amount of crap, BTW. Anyway, to answer that question will presumably require someone to either try it, or figure out what is actually needed, crypto-wise. > > -- > 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 Fri Oct 27 20:56:56 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 EAECEE50E78 for ; Fri, 27 Oct 2017 20:56:56 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.cran.org.uk (muon.bluestop.org [IPv6:2605:7700:0:8:1:0:4a32:3323]) (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 CF8EF77064 for ; Fri, 27 Oct 2017 20:56:56 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D76769A57; Fri, 27 Oct 2017 20:56:48 +0000 (UTC) Received: from muon.cran.org.uk ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ccp1ACFSuLmJ; Fri, 27 Oct 2017 20:56:47 +0000 (UTC) Received: from [192.168.1.67] (c-73-131-237-119.hsd1.ut.comcast.net [73.131.237.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 27 Oct 2017 20:56:47 +0000 (UTC) To: freebsd-arch@freebsd.org From: Rebecca Cran Subject: Re NVDIMM status report (2017-03-25) Cc: Ravi Pokala Message-ID: <6a504eb3-0194-850a-4f36-345b7a2a738e@bluestop.org> Date: Fri, 27 Oct 2017 14:56:47 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed 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: Fri, 27 Oct 2017 20:56:57 -0000 I'm replying to the original message at https://lists.freebsd.org/pipermail/freebsd-arch/2017-March/018165.html (sorry, I'm not sure how to get the raw email to import and reply to properly). "Traditional" NVDIMMs have been standardized under JEDEC with the name 'NVDIMM-N': NVDIMM-P is an upcoming specification that will be for 'persistent'  or 'storage class' memory modules such as 3D X-Point. NVDIMM-F is another standard, that puts NAND directly on the memory bus and allows accesses directly. It's very slow, and only allows block accesses. NVDIMM-P should be in-between NVDIMM-N and NVDIMM-F in terms of speed/latency. In terms of proprietary interfaces, there are at least 3 ACPI DSMs: HPE, Microsoft[0] and Intel[1]. The ACPI Working Group has started to work on bringing them together under a single specification, but it's still early days. JEDEC has however published the BAEBI (Byte Addressable Energy Backed Interface) that's the basis for the DSM, and runs over I2C. OEMs often lock down access to the I2C bus on boot however, requiring all accesses to be via ACPI. There's currently no widespread support in UEFI for NVDIMMs: I have prototype code running which allows OVMF running under Qemu to enumerate them and populate the "Persistent Memory" entry of the 'memmap' shell command, but that's as far as it goes so far. -- Rebecca Cran [0] https://msdn.microsoft.com/en-us/library/windows/hardware/mt604741(v=vs.85).aspx [1] http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf From owner-freebsd-arch@freebsd.org Fri Oct 27 21:12:59 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 8BE6DE51271 for ; Fri, 27 Oct 2017 21:12:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 2224377822 for ; Fri, 27 Oct 2017 21:12:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v9RLCmpB095854 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Oct 2017 00:12:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v9RLCmpB095854 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v9RLCmf3095853; Sat, 28 Oct 2017 00:12:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 Oct 2017 00:12:48 +0300 From: Konstantin Belousov To: Rebecca Cran Cc: freebsd-arch@freebsd.org, Ravi Pokala Subject: Re: Re NVDIMM status report (2017-03-25) Message-ID: <20171027211248.GL2566@kib.kiev.ua> References: <6a504eb3-0194-850a-4f36-345b7a2a738e@bluestop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6a504eb3-0194-850a-4f36-345b7a2a738e@bluestop.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Fri, 27 Oct 2017 21:12:59 -0000 On Fri, Oct 27, 2017 at 02:56:47PM -0600, Rebecca Cran wrote: > I'm replying to the original message at > https://lists.freebsd.org/pipermail/freebsd-arch/2017-March/018165.html > (sorry, I'm not sure how to get the raw email to import and reply to > properly). > > > "Traditional" NVDIMMs have been standardized under JEDEC with the name > 'NVDIMM-N': NVDIMM-P is an upcoming specification that will be for > 'persistent' or 'storage class' memory modules such as 3D X-Point. > NVDIMM-F is another standard, that puts NAND directly on the memory bus > and allows accesses directly. It's very slow, and only allows block > accesses. NVDIMM-P should be in-between NVDIMM-N and NVDIMM-F in terms > of speed/latency. > > > In terms of proprietary interfaces, there are at least 3 ACPI DSMs: HPE, > Microsoft[0] and Intel[1]. The ACPI Working Group has started to work on > bringing them together under a single specification, but it's still > early days. JEDEC has however published the BAEBI (Byte Addressable > Energy Backed Interface) that's the basis for the DSM, and runs over > I2C. OEMs often lock down access to the I2C bus on boot however, > requiring all accesses to be via ACPI. > > There's currently no widespread support in UEFI for NVDIMMs: I have > prototype code running which allows OVMF running under Qemu to enumerate > them and populate the "Persistent Memory" entry of the 'memmap' shell > command, but that's as far as it goes so far. Perhaps I have some more code. It is more of 'me too' response than something that can be used practically. My WIP patch is at https://kib.kiev.ua/kib/nvdimm.1.patch . Half of it is the KPI to map very large physical memory ranges into KVA, another half is the germ of the driver. The driver provides two devices: one is /dev/nvdimm_spaX for each SPA region, which allows io and zero-copy userspace mapping. Another device is /dev/spaX which is in fact geom and it can be mounted after formatting in UFS. Namespaces support is missed, but planned, same for the blocks access interface. From owner-freebsd-arch@freebsd.org Sat Oct 28 02:26:17 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 83E20E585EF; Sat, 28 Oct 2017 02:26:17 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 026B98456F; Sat, 28 Oct 2017 02:26:16 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190e-651ff70000007a39-ef-59f3eac0500f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 1B.04.31289.0CAE3F95; Fri, 27 Oct 2017 22:26:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v9S2Q3wl031486; Fri, 27 Oct 2017 22:26:05 -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 v9S2PvpY019877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Oct 2017 22:25:59 -0400 Date: Fri, 27 Oct 2017 21:25:57 -0500 From: Benjamin Kaduk To: Ben Laurie Cc: Poul-Henning Kamp , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028022557.GE96685@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixG6nonvw1edIg0XX+S0Wzea0+Db9L4vF 7OnTmCy2b/7HaNGz6QmbxYdv/A5sHjM+zWfx2Nw0h83j3o4JTB6f9k9mC2CJ4rJJSc3JLEst 0rdL4Mq423GQreCzcMWJny/ZGxibBboYOTkkBEwkTk9Yy9TFyMUhJLCYSeLwtMWsEM5GRok5 r99AOVeZJJovH2ICaWERUJX4230UzGYTUJN4vLeZFcQWEZCT+H37CwtIA7PABiaJp4uugRUJ C8hIHDx7CczmBdp38dtbFoipPxglHuw/zAyREJQ4OfMJC4jNLKAlcePfS6AGDiBbWmL5Pw6Q MKdAoMTyTyvBlokKKEvM27eKbQKjwCwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI11gvN7NELzWldBMjKMQ5Jfl2ME5q8D7EKMDBqMTDK5H7OVKINbGsuDL3EKMkB5OSKO++ 858ihfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwXsgHKudNSaysSi3Kh0lJc7AoifNuC9oVKSSQ nliSmp2aWpBaBJOV4eBQkuA99xKoUbAoNT21Ii0zpwQhzcTBCTKcB2j4c5Aa3uKCxNzizHSI /ClGS45NN+/+YeLY8P0BkHw283UDsxBLXn5eqpQ47weQBgGQhozSPLiZoJQlkb2/5hWjONCL wrzCwAQmxANMd3BTXwEtZAJa2KT6AWRhSSJCSqqB8VjLFD9boZ7dM0W8cnjqRbse1BbEHlHN L163r+6yMltgdFiTbMW2RMmM2P/e92d2ZXz781tlm3Xw5ivij2ysThh01+5ZYmr7Lv2Cbuiu TQn35+wIDFee9UCoRPT4X6++ZdrvuRj/TvH56cE3va1PTOKtttnUP4+/KJ4UDdu4htElMMow 9U+QEktxRqKhFnNRcSIAIRI7gTQDAAA= 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: Sat, 28 Oct 2017 02:26:17 -0000 On Fri, Oct 27, 2017 at 09:20:13PM +0100, Ben Laurie wrote: > On 27 October 2017 at 20:24, Poul-Henning Kamp wrote: > > -------- > > In message > > , Ben Laurie writes: > > > >>OpenSSL includes (and is used for) lots of crypto that is not used in > >>SSL - since BearSSL targets SSL/TLS only, it can't, presumably, be > >>used to replace all uses of OpenSSL. > > > > Which implicitly raises the question if we really need all the > > boatloads of crap OpenSSL drags in, or if we would be in a better > > position with something simpler and saner ? > > Indeed it does. Perhaps worth noting that since it was staffed, > OpenSSL has removed a fair amount of crap, BTW. Full disclosure: I am an OpenSSL committer (but not a member of the management committee). It is true that a lot of crap has been removed recently, and the test suite has gotten more robust (not the least due to the addition of a large portion of the BoringSSL test suite). But we're still constrained by a heavy burden of API/ABI stability in major release branches (compounded by a promise to make the next release branch 1.1.1, with TLS 1.3 support, so ABI-breaking changes are currently on indefinite hold). That, combined with an existing public API that grew quite organically and without a great deal of thought, still makes for a system that is hard to maintain well. 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 is, we (FreeBSD) would be stuck supporting an OpenSSL version that is EOL upstream, which is not a great position to be in. On the other hand, upstream OpenSSL is taking ABI compatibility more seriously, so it might be reasonable to (e.g.) upgrade from 1.1.0 to 1.1.1 within a FreeBSD stable branch than it would (not) have been to upgrade from 1.0.1 to 1.0.2. That might make the support lifecycle concerns go away. > Anyway, to answer that question will presumably require someone to > either try it, or figure out what is actually needed, crypto-wise. Indeed, and I do not think I can volunteer. -Ben P.S., when Chris H mentioned "an alternative with a long history of reliability, safety, and a great deal of scrutiny by seasoned developers, and security engineers", I couldn't really tell what that alternative was supposed to be. From owner-freebsd-arch@freebsd.org Sat Oct 28 08:03:38 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 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 cc: Ben Laurie , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" 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-Type: text/plain; charset="us-ascii" 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-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: Sat, 28 Oct 2017 08:03:38 -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. From owner-freebsd-arch@freebsd.org Sat Oct 28 08:17: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 32188E5ED4F; Sat, 28 Oct 2017 08:17:52 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D26167A53; Sat, 28 Oct 2017 08:17:51 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id v9S8Hodv018008 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Oct 2017 01:17:50 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id v9S8Hogh018007; Sat, 28 Oct 2017 01:17:50 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Oct 2017 01:17:50 -0700 From: John-Mark Gurney To: Eric McCorkle Cc: "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028081750.GG42467@funkthat.com> Mail-Followup-To: Eric McCorkle , "freebsd-arch@freebsd.org" , freebsd-security@freebsd.org, "freebsd-hackers@freebsd.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 28 Oct 2017 01:17:50 -0700 (PDT) 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: Sat, 28 Oct 2017 08:17:52 -0000 Eric McCorkle wrote this message on Thu, Oct 26, 2017 at 20:29 -0400: > 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). I wouldn't call them crypto and opencrypto.. There is the opencrypto API, as documented by crypto(9), and then there are various undocumented API's in sys/crypto that give direct software access to various hash and cipher functions... > * 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. The opencrypto API is a very terrible API. There are lots of issues w/ it, and it should be overhauled. The algorithm agility that it provides is more complex than needed, and very few people need the options it provides. It increases driver complexity to support the many different ways that encryption and mac algorithms can be ordered... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Sat Oct 28 12:36:57 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 282C1E425B0; Sat, 28 Oct 2017 12:36:57 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 61F0C6E43C; Sat, 28 Oct 2017 12:36:55 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074422-b6dff7000000159a-82-59f478ad6dd6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 22.44.05530.EA874F95; Sat, 28 Oct 2017 08:31:43 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v9SCVbZ3006042; Sat, 28 Oct 2017 08:31:38 -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 v9SCVWaM031555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 28 Oct 2017 08:31:35 -0400 Date: Sat, 28 Oct 2017 07:31:32 -0500 From: Benjamin Kaduk To: Poul-Henning Kamp Cc: Ben Laurie , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Subject: Re: Crypto overhaul Message-ID: <20171028123132.GF96685@kduck.kaduk.org> References: <13959.1509132270@critter.freebsd.dk> <20171028022557.GE96685@kduck.kaduk.org> <23376.1509177812@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23376.1509177812@critter.freebsd.dk> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixG6nrru+4kukwYsnKhaLZnNafJv+l8Vi 9vRpTBbbN/9jtOjZ9ITN4sM3fgc2jxmf5rN4bG6aw+Zxb8cEJo9P+yezBbBEcdmkpOZklqUW 6dslcGVsWb2KseAMd8W/+/cZGxhXcHYxcnJICJhI7HrTx9jFyMUhJLCYSeL4ngYoZyOjxJG7 i9khnKtMEnv6DrKCtLAIqEqcvXOcEcRmE1CTeLy3GSwuIqAlsXb2WSaQBmaB2UwSq4+1gBUJ C8hIHDx7iQnE5gXaN+3FDmaIqaeZJD433mOESAhKnJz5hAXEZgaadOPfS6AGDiBbWmL5Pw6Q MKeAkcS2prNgy0QFlCXm7VvFNoFRYBaS7llIumchdC9gZF7FKJuSW6Wbm5iZU5yarFucnJiX l1qka6qXm1mil5pSuokRHOIuSjsYJ/7zOsQowMGoxMMrkfs5Uog1say4MvcQoyQHk5Io777z nyKF+JLyUyozEosz4otKc1KLDzFKcDArifAGlX+JFOJNSaysSi3Kh0lJc7AoifNuC9oVKSSQ nliSmp2aWpBaBJOV4eBQkuBdC9IoWJSanlqRlplTgpBm4uAEGc4DNPw02PDigsTc4sx0iPwp RkuOTTfv/mHi2PD9AZB8NvN1A7MQS15+XqqUOK8WSIMASENGaR7cTFDKksjeX/OKURzoRWHe RpAqHmC6g5v6CmghE9BCDUmwhSWJCCmpBkYOx6rmdXYcj5lerOv/uaev2n/Lpo08oU1xgf8v ntrGNVX31/I9Ebl/Q91UfGXUl9j/+P3P9ODTwHl/vNWurT7JYiIeb7ipXzSPcSZ/WcPvhzcY Ju7utrj6peyGWuONUxyXZRMX2yXmir7MqMqM5ul6JfzJ9qHStZnrr17bNn+S/Hzh+++X5vxV YinOSDTUYi4qTgQA0N6zLDQDAAA= 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: Sat, 28 Oct 2017 12:36:57 -0000 On Sat, Oct 28, 2017 at 08:03:32AM +0000, Poul-Henning Kamp wrote: > -------- > 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. Those are all fine reasons for an individual to want OpenSSL gone from the tree, and I can't really dispute any of them for the 1.0.x series. 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. Regardless, the point I was intending to make is that, fine reasons those are, they in and of themselves may not be enough to overcome the weight of POLA for staying with OpenSSL. I do, however, remember a few years ago a Security Officer raising concerns about the support lifecycle mismatch, and in that context that reason does seem to be able to overcome the weight of POLA. That is, I was talking about history. We should of course make our own, fresh, decision about whether your reasons are currently enough to outweigh POLA, for the present discussion. -Ben From owner-freebsd-arch@freebsd.org Sat Oct 28 13:16:03 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 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 cc: Ben Laurie , Eric McCorkle , "freebsd-security@freebsd.org security" , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" 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-Type: text/plain; charset="us-ascii" 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-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: Sat, 28 Oct 2017 13:16:03 -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. From owner-freebsd-arch@freebsd.org Sat Oct 28 14:52:58 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 83391E4524E for ; Sat, 28 Oct 2017 14:52:58 +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 EC506716D8 for ; Sat, 28 Oct 2017 14:52:57 +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 T2rk1w0060HtmFq012rkyU; Sat, 28 Oct 2017 15:51:44 +0100 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=Hw8hSUHECGJrHUsrF90A:9 a=QEXdDO2ut3YA:10 From: Jonathan de Boyne Pollard Subject: New reboot flag: -c for 'power cycle' To: FreeBSD Arch , FreeBSD Hackers Message-ID: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> Date: Sat, 28 Oct 2017 15:51:43 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 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: Sat, 28 Oct 2017 14:52:58 -0000 Warner Losh: > Since init has no controlling terminal, SIGWINCH is useless to it anyway. This is untrue for two reasons. First, for some years now the nosh toolset's system manager has been recognizing SIGWINCH on FreeBSD/TrueOS for Linux compatibility; as on Linux it is sent to process #1 in response to a kernel virtual terminal attention key sequence. Second, that argument is fallacious because it would also apply to controlling-terminal-generated signals such as SIGINT and clearly does not given that SIGINT is useful to process #1. So what I am doing in the nosh toolset for the forthcoming version 1.36 is this: * The compatibility shutdown command now sports a new -c/--powercycle option. * The compatibility reboot, halt, and poweroff commands now sport a new -c/--powercycle option, for the benefits of cruel system administrators. * There is a new compatibility fastpowercycle/powercycle command, with all of the same options for cruel system administrators. * 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. * The system-control init subcommand now sports a new c/C argument, by analogy to h/H. This is of course thus reflected automatically in the compatibility telinit command and the initctl-read server. From owner-freebsd-arch@freebsd.org Sat Oct 28 15:30:08 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 7BA02E45EF4 for ; Sat, 28 Oct 2017 15:30:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 2CBD572403 for ; Sat, 28 Oct 2017 15:30:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id e89so18522405ioi.11 for ; Sat, 28 Oct 2017 08:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nGYU2ZWPBnItcaOT5DNyvM2UB1wTAg85F+PrNlqU8WM=; b=wv/qq7zuq/NFrvbBXA+u0gHfe65CuyRTxuDVq32ubG56ziKQLk/NkvjP04YrKdFDwr zz94cGyODbCfb7VjgxoOAC7bCAZw5IbfEDirXNwYpImyqE3gT6V5BrwjdRgkdC5XszhL HEltQWX7ajO2lquqbCTzQQKM/4Oj+Q0+rfj1wEF7Sumy4yl+wEBbOvKHzD5nLvy6J5eq +XE2SNAQdot3HvYF+lM85HuMgPrsAK0Ysyg/lwvnLzUo7gUrY1pb6vIZVkU81zgivbRy PSNDz5BehUgE3fsvWBypo9ICDaOSAqeNOKaj2k7lRFtoGeoDfUqQDKpmazGv9HdhFkTT P1DQ== 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=nGYU2ZWPBnItcaOT5DNyvM2UB1wTAg85F+PrNlqU8WM=; b=mHYW2BQoO29XUcG/X7gF5CVIpjZW4HeWmKOiZZcdFp/hTbGka65m39UfawuidlWhyN 2pBqbUDY08oP6H60Grq6hVc0afg6+nSL7zcvOvf86lcoo1aQNjNDwbPShaN/z2clwtXL J/G3bJfVcjt83suT88qQMJaad49Bonm3Y1S/M7QWCaemnWPil0r6tExjtYbof3hcmfR+ GgDbgkXnuCMfIyZr79dOpu5gXz1yHtXrn1zy4C7HE1GnTAjR3MdtUYGSUQAXAV0f+Z5o fLmPQLElMDlKccsKBIb/a15pAJ6dGK75JooYjEEbFNchadBvx59fzK76s4FQpA2iTvWd A+rw== X-Gm-Message-State: AMCzsaU3UHD3YwQrylhoFhuvc1bDwqbwgHUHe/hFWr/tbzEU8S9CQT/9 nTjMDjUhtK+zVRT4QyUPfS7fKIJIpm+LVobhQZjeeA== X-Google-Smtp-Source: ABhQp+SmGvL4/KSmQtOWBHTQBq+6dSrS69BWjIar4KFPe605yKR5arDFQv5gyRt4SymXDHL7slRHK4kw0EXDpLs19P4= X-Received: by 10.36.184.5 with SMTP id m5mr5259070ite.69.1509204606969; Sat, 28 Oct 2017 08:30:06 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.57.22 with HTTP; Sat, 28 Oct 2017 08:30:06 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:817e:dabb:4900:7bcb] In-Reply-To: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> References: <01741ade-cd76-3e7a-2b75-0d9984a6ee90@NTLWorld.COM> From: Warner Losh Date: Sat, 28 Oct 2017 09:30:06 -0600 X-Google-Sender-Auth: VlqCl_-Fxp-__35b8txd5dx0y5M Message-ID: Subject: Re: New reboot flag: -c for 'power cycle' To: Jonathan de Boyne Pollard Cc: FreeBSD Arch , FreeBSD Hackers 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: Sat, 28 Oct 2017 15:30:08 -0000 On Sat, Oct 28, 2017 at 8:51 AM, Jonathan de Boyne Pollard via freebsd-arch wrote: > > Warner Losh: > > > Since init has no controlling terminal, SIGWINCH is useless to it anyway. > > This is untrue for two reasons. First, for some years now the nosh > toolset's system manager has been recognizing SIGWINCH on FreeBSD/TrueOS > for Linux compatibility; as on Linux it is sent to process #1 in response > to a kernel virtual terminal attention key sequence. Second, that argument > is fallacious because it would also apply to controlling-terminal-generated > signals such as SIGINT and clearly does not given that SIGINT is useful to > process #1. > It's useless for its intended purpose, which is why it can be appropriated. 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.. > So what I am doing in the nosh toolset for the forthcoming version 1.36 is > this: > Might want to hold off on this a smidge... See below... > * The compatibility shutdown command now sports a new -c/--powercycle > option. > > * The compatibility reboot, halt, and poweroff commands now sport a new > -c/--powercycle option, for the benefits of cruel system administrators. > > * 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. > * 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. > * The system-control init subcommand now sports a new c/C argument, by > analogy to h/H. > > This is of course thus reflected automatically in the compatibility > telinit command and the initctl-read server. > Warner From owner-freebsd-arch@freebsd.org Sat Oct 28 23:31:07 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 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-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: Sat, 28 Oct 2017 23:31:07 -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.