Date: Thu, 19 Oct 2017 22:03:28 -0400 From: Eric McCorkle <eric@metricspace.net> To: freebsd-arch@freebsd.org Subject: Re: boot1.efi future Message-ID: <56a95153-e970-990c-d3f1-453be4da7150@metricspace.net> In-Reply-To: <CANCZdfqvAVoKHef36fAhpDhuaO-VoDjkYUHP9QcLp5_wyOpCng@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/19/2017 13:18, Warner Losh wrote: > On Oct 19, 2017 10:03 AM, "Simon J. Gerraty" <sjg@juniper.net> wrote: > > Warner Losh <imp@bsdimp.com> wrote: >> There's lots of details to get right before we can make the final switch, >> but I think it's in the interest of the project to do so. > > Just one comment that may or may not be relevant depending on the overal > plan. > > 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. > > From that pov the initial boot bits can change as you like without > affecting the above. Is that the plan? > > It only matters I guess in terms of the effort to upstream - assuming > there is interest from other embedded vendors. 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56a95153-e970-990c-d3f1-453be4da7150>