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

[Simon Glass]

Hi Michael,

On Wed, 28 Jul 2021 at 09:54, Michael Nazzareno Trimarchi
<michael at amarulasolutions.com> wrote:
>
> 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

I'm not quite sure how to read that diagram. I think we should have
SPLA_ and SPL_B (and perhaps SPL_RECOVERY) so it matches with U-Boot
proper.

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

Only if there is space to store both the early-init code and the
verified boot. So for coral this is not possible.

But if I understand things correctly, then yes this is the idea.

Regards,
Simon



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