Hi Tom, (just to reply to this old email)
On Mon, 2 Aug 2021 at 12:54, Tom Rini <tr...@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 <tr...@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 <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? > > > > 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
