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 <tr...@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 <s...@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
signature.asc
Description: PGP signature