Date: Thu, 19 Oct 2017 22:05:51 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: Eric McCorkle <eric@metricspace.net> Cc: <freebsd-arch@freebsd.org>, <sjg@juniper.net> Subject: Re: boot1.efi future Message-ID: <82995.1508475951@kaos.jnpr.net> In-Reply-To: <56a95153-e970-990c-d3f1-453be4da7150@metricspace.net> References: <CANCZdfqWSqjdRGetoiscEKJ_dNf3JgOQ2S9mzA0v1mP9PGAy=g@mail.gmail.com> <44307.1508432567@kaos.jnpr.net> <CANCZdfrdKTDZW8y2YLng9rLmawwcDEJ=7tf5K-yh6=aDuCGg_w@mail.gmail.com> <CANCZdfqvAVoKHef36fAhpDhuaO-VoDjkYUHP9QcLp5_wyOpCng@mail.gmail.com> <56a95153-e970-990c-d3f1-453be4da7150@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric McCorkle <eric@metricspace.net> wrote: > > I've implemented verification in the freebsd loader, along the lines > > previously mentioned, for us this pretty much closes the secure-boot > > gap - loader verifies kernel and its initial rootfs so init and etc/rc. > > Which then gets us to mac_veriexec. > > Do I assume correctly that this is based on the NetBSD mac-based > verification stuff? ie. Not the public-key crypto stuff I've talked about? I didn't want to thread-jack... I've not looked at what's in NetBSD in this area for a decade at least, but I ported the original veriexec from NetBSD to Junos about a dozen years or so ago. More recently stevek re-implemented it for FreeBSD 10's MAC framework - the diffs (most of them anyway) have been sitting in phabricator for a year or so... The loader implementation shares no code with the above, but uses the same verification model and leverages the same signed manifests. Thus it retains all the flexibility of using X.509 certificate chains to verify the signatures on the manifests. This is very important for us, because it allows a 10 year old binary to verify the latest signatures - provided that the RootCA certs have not changed. For Junos the loader knows two RootCA's one for RSA and one for ECDSA - that's all it needs. We can tollerate more limited signing methods for the loader itself, to fit in to various secure BIOS/boot environments, but from there we want all the flexibility we can get. --sjg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82995.1508475951>