[PATCH v3 0/7] vpl: Introduce a verifying program loader

[Tom Rini]

On Wed, Jul 28, 2021 at 09:33:56AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 28 Jul 2021 at 08:35, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > no standard way of implementing it for a board. At present the various
> > > > required pieces must be built up separately, to produce a working
> > > > implementation. In particular, there is no built-in support for selecting
> > > > A/B boot or recovery mode.
> > > >
> > > > This series introduces VPL, a verified program loader. Its purpose is to
> > > > run the verified-boot process and decide which SPL binary should be run.
> > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > verified boot. So far, only the phase itself is added along with some
> > > > Kconfig options. The next step is to create a build for sandbox.
> > > >
> > > > Changes in v3:
> > > > - Move VPL Kconfig options to a separate patch
> > > > - Add full build support for VPL
> > > >
> > > > Changes in v2:
> > > > - Add some more VPL Kconfig options
> > > >
> > > > Simon Glass (7):
> > > >   doc: Convert SPL documentation to ReST
> > > >   doc: Expand SPL docs to explain the phase and config
> > > >   test: Tidy up test building with SPL
> > > >   spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > >   binman: Add VPL support
> > > >   Introduce Verifying Program Loader (VPL)
> > > >   vpl: Add Kconfig options for VPL
> > >
> > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > if that helps.
> >
> > Perhaps some of these general questions would be answered with seeing an
> > implementation for not just sandbox, but real hardware too.  But I'm
> > missing what this provides exactly that we can't do already, or that
> > would justify a whole new stage rather than just some updates within
> > existing logic.  What is this doing over SPL_FIT_SIGNATURE for example?
> > Checking in with a TPM to confirm good measurements?  Having written
> > that out, now I really do want to see this implemented on real hardware
> > much more so than sandbox.
> 
> Yes it was actually implemented on coral, an x86 Chromebook which is
> in-tree. I have various patches to come but the docs are at [1]
> 
> The core reason for it is that SPL sets up SDRAM (and perhaps other
> things) so needs to be updateable, so we cannot boot the vboot logic
> in SPL. TPL often has very small size limits so it is difficult to put
> it in there. I am thinking that VPL can be an optional phase used only
> if verified boot is enabled. That makes it easy since it has a defined
> purpose which can be enabled/disabled.
> 
> BTW in doing this I wonder whether we should look again at the
> SPL_TPL_ Makefile variables. Do you think PHASE might be better?
> 
> Regards,
> Simon
> 
> [1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst

There's always a "no updates before HERE" line to draw, as you need a
fall-back option.  Since you mention SDRAM, does that mean both TPL and
VPL are running in SRAM/similar space?  If so, why isn't this just part
of TPL, for when you have "a lot" of pre-SDRAM memory to use?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210728/a7829598/attachment.sig>