Date: Fri, 6 Jul 2018 13:01:20 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: <cem@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, <sjg@juniper.net> Subject: Re: [Differential] D16155: Add veriexec to loader Message-ID: <21993.1530907280@kaos.jnpr.net> In-Reply-To: <CAG6CVpVc6cCURhNsCoqQXv1OcrHrvU90YdFEvTvk4=-1gyR=0g@mail.gmail.com> References: <differential-rev-PHID-DREV-jfitweed3urwpaigoztb-req@FreeBSD.org> <84d9b7dd268a8cb64b51e4c49753bed8@localhost.localdomain> <93705.1530850590@kaos.jnpr.net> <CAG6CVpVc6cCURhNsCoqQXv1OcrHrvU90YdFEvTvk4=-1gyR=0g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21993.1530907280>