Hi Michael, On Wed, 28 Jul 2021 at 09:54, Michael Nazzareno Trimarchi <mich...@amarulasolutions.com> wrote: > > Hi > > On Wed, Jul 28, 2021 at 5:34 PM Simon Glass <s...@chromium.org> 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. > > > > > > > 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 > mich...@amarulasolutions.com > __________________________________ > > Amarula Solutions BV > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > T. +31 (0)85 111 9172 > i...@amarulasolutions.com > www.amarulasolutions.com
