boot1.efi future

Simon J. Gerraty sjg at juniper.net
Fri Oct 20 05:06:20 UTC 2017


Eric McCorkle <eric at 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


More information about the freebsd-arch mailing list