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

[Michael Nazzareno Trimarchi]

Hi

On Wed, Jul 28, 2021 at 5:34 PM Simon Glass <sjg at chromium.org> 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.
> > > >

Let's try to understand. So we can have:

TPL (redundant most of cpus support it) -> VPL -\

      -> SPL1 -\ = > UBOOT_B e/o fitImage

                    | -> ATF1
                    | -> TEE1

      -> SPL2  -\ => UBOOT_A e/o fitImage
                    | => ATF2
                    | => TEE2

If you have this kind of system TPL and VPL can be combined. Is this
the scenario we will use with this patchset?

The funny thing here is that a lot of people ask to update the TPL. After
adding the VPL the communication will happen using hob memory area?

One of the most interesting parts will be to tag the TPL(x) to know what of them
the bootrom load.

Michael


> > > > 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



--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael at amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info at amarulasolutions.com
www.amarulasolutions.com