[Differential] D16155: Add veriexec to loader

[Simon J. Gerraty]

> 1. It's unclear in what context files are used (loader, userspace,
> and/or kernel).  Some files in directories are built in multiple
> contexts, but not others, and the contexts aren't clear from the
> pathnames.  That lead(s) to some confusion.  For crypto review you

Originally all this was only for the loader.
But then the need for a veriexec userland tool that would verify
manifests before feeding the kernel was brought up.
A subset of libve is needed for that.

The Makefile.libsa.inc in both libbearssl and libve show what get's used
by libsa - for loader.

Of libve only vets.c (trust store) and the openpgp/ code (optionally)
is needed for userland.

> really want clarity.  It is almost certainly better to break this into
> several pieces.  I.e., the mechanical build system changes to import
> bearssl can be separated out; you could maybe add loader-only
> verification code next, then bring in the kernel pieces, then
> userspace (as separate reviews).  You know this work better than I do;
> how you choose to split it is up to you.  But I would encourage
> smaller pieces.

Yes, the initial review was bigger than I'd expected - beyond the point
at which a gui is helpful.

I'm open to alternate arrangements - the current diff is a minimal
re-org to fit into the new stand/ environment and present the work so
others can provide feedback.

> 2. A lot of the responses to my questions or comments are "JunOS does
> (or has done) it this way."  Those are great rationales for Juniper
> continuing to use the existing design in its commercial product!  But
> this isn't JunOS, and booting JunOS is useless to FreeBSD.  If all you

Perhaps I've not made myself clear.

Junos is a FreeBSD based OS, it's booting requirements are in some
respects more complicated than a typical FreeBSD install - so it serves
as a useful example.

I shoud also point out that we always provide the kernel with an
md_image for its initial rootfs - and that md_image is verified by the
loader - obviating the need for any of this stuff in the kernel itself.
Everything needed to get mac_veriexec initialized and enforced is in
that md_image.

If that's not done, then someone would need to consider adding code to
kernel to verify init, and the rc scripts etc etc.

> want to do with the changes is boot JunOS, I don't see any reason to
> include it in FreeBSD.  If your concern is that the implementations

No, we could skip upstreaming this completely - but other vendors who
also use FreeBSD have expressed interest.

> will diverge slightly, well, they will.  That's sort of the nature of

That doesn't concern me at all.

> being a downstream commercial product of FreeBSD.  For anything
> removed in FreeBSD (i.e., obsolete SHA1 support, or even RSA/ECDSA

Sorry, if you want to support signature other methods you are welcome to
add them.  Many of those vendors interested in this work face the same
limitations we do - needing to use US Govt approved algorithms.

Perhaps you could enumerate some of the alternatives you'd support.
You've veto'd pretty much everything here, so what do you think the
modern world needs?

Eg. X.509 is horrible - everyone agrees, but what is the alternative
that offers the same flexibility?
RSA and ECDSA are old fasioned?
What are the proposed alternatives? and what libraries implement them
that are small enough to incorporate into the loader?

This project has been on my todo list for a decade, but was not viable
until BearSSL showed up last year.
OpenSSL was simply too big - the loader stops working somewhere around 500K
(based on my experiments yesterday) and the OpenSSL code required is 3M+

--sjg