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

[Simon Glass]

Hi Tom,

(just to reply to this old email)

On Mon, 2 Aug 2021 at 12:54, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Jul 28, 2021 at 12:37:55PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> >
> > On Wed, 28 Jul 2021 at 11:37, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > 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?
> >
> > It depends on the architecture. For coral (and other modern x86
> > devices) there is 32KB which is enough to run TPL but not enough to
> > run VPL. So TPL sets up 'Cache-as-RAM' which provides additional SRAM.
> > Other architectures may have their own constraints.
>
> And in this case then VPL sets up DRAM?

No, SPL. Nothing changes there.

>
> > But another key difference is that we use OF_PLATDATA in TPL and that
> > is fine for the basic init needed there. But VPL needs lots of drivers
> > as well as info about the firmware image layout so it adds to the work
> > needed to get them running in that environment. So ideally, VPL can be
> > built without OF_PLATDATA.
> >
> > Or put it another way, TPL needs to be as small as possible so it can
> > run on the widest array of devices. VPL is an optional phase (only
> > used with verified boot) so we should not pollute TPL with that. I
> > have a lot of other thoughts about all of this, some of which are in
> > the VBE doc...
>
> Right, the intention behind allowing "TPL" in-tree was that we have
> enough cases where we're size constrained and just need to allow for
> something "functional enough".  This was what the old PowerPC "SPL" was
> about, and SoCs keep coming out with relatively tiny initial memory
> spaces.
>
> I guess my concerns at the high level fall in to a few spots:
> - I don't really like the idea of having to introduce yet another stage.

Well I've been avoiding it for years...

>   At that point, what infrastructure from U-Boot is it really even
>   using?

Well the verification will be in VPL in U-Boot.

> - In order to use this we're now needing platforms to support TPL to add
>   in VPL.

Not necessarily. If the platform has enough memory to enable
verification in TPL then that is still an option.

> - That kind of ties in to another part of the issue I see.  Why is this
>   not just a feature to enable in earlier stage?

Yes that's possible, but it cannot be implemented in TPL in quite a
few platforms, as I see it.

> - Why do we have both verified and "A/B or recovery" in the same spot?

I'm not sure what this means, sorry.

>
> Some of this I guess comes down to my thinking about how yes, x86 is
> constrained, but we have a lot of other platforms with 128/256/way more
> pre-SDRAM memory available and verified is the key feature to enable
> rather than A/B update.  And again, what does the verified part of this
> provide over FIT_SIGNATURE?  Outside of that A/B case, at least.

It uses FIT_SIGNATURE, but with U-Boot being the target binary. So
there are two updateable parts: firmware and kernel.

Regards,
Simon