Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
Hi Tom, (just to reply to this old email) On Mon, 2 Aug 2021 at 12:54, Tom Rini 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 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 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 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
Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
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 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 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 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? > 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
Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
Hi Tom, On Wed, 28 Jul 2021 at 11:37, Tom Rini 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 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 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. 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... Regards, SImon
Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
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 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 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
Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
Hi Michael, On Wed, 28 Jul 2021 at 09:54, Michael Nazzareno Trimarchi wrote: > > Hi > > On Wed, Jul 28, 2021 at 5:34 PM Simon Glass wrote: > > > > Hi Tom, > > > > On Wed, 28 Jul 2021 at 08:35, Tom Rini 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 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
Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
Hi On Wed, Jul 28, 2021 at 5:34 PM Simon Glass wrote: > > Hi Tom, > > On Wed, 28 Jul 2021 at 08:35, Tom Rini 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 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 If you have this kind of system TPL and VPL can be combined. Is this the scenario we will use with this patchset? 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
Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
Hi Tom, On Wed, 28 Jul 2021 at 08:35, Tom Rini 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 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
Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
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 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. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
Hi Tom, On Sun, 11 Jul 2021 at 20:19, Simon Glass 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. Regards, Simon
[PATCH v3 0/7] vpl: Introduce a verifying program loader
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
Kconfig| 10 +
Makefile | 15 +-
arch/sandbox/Kconfig | 8 +
common/Kconfig | 67 ++
common/spl/Kconfig | 226 +++--
common/spl/spl.c | 25 ++-
doc/develop/index.rst | 1 +
doc/{README.SPL => develop/spl.rst}| 99 +
drivers/clk/Kconfig| 10 +
drivers/core/Makefile | 2 +-
drivers/gpio/Kconfig | 11 +
drivers/i2c/Kconfig| 11 +
drivers/misc/Kconfig | 19 ++
drivers/pinctrl/Kconfig| 18 +-
drivers/rtc/Kconfig| 9 +
drivers/serial/Kconfig | 20 ++
drivers/sysreset/Kconfig | 10 +
drivers/timer/Kconfig | 10 +
include/bootstage.h| 2 +
include/linux/kconfig.h| 3 +
include/spl.h | 20 +-
lib/Kconfig| 62 ++
scripts/Kbuild.include | 4 +
scripts/Makefile.autoconf | 12 ++
scripts/Makefile.build | 4 +
scripts/Makefile.lib | 5 +
scripts/Makefile.spl | 37 +++-
test/test-main.c | 2 +-
tools/binman/etype/u_boot_vpl.py | 42
tools/binman/etype/u_boot_vpl_bss_pad.py | 44
tools/binman/etype/u_boot_vpl_dtb.py | 28 +++
tools/binman/etype/u_boot_vpl_expanded.py | 45
tools/binman/etype/u_boot_vpl_nodtb.py | 42
tools/binman/ftest.py | 110 --
tools/binman/state.py | 3 +-
tools/binman/test/082_fdt_update_all.dts | 2 +
tools/binman/test/201_u_boot_vpl.dts | 11 +
tools/binman/test/202_u_boot_vpl_nodtb.dts | 13 ++
tools/binman/test/203_fdt_incl_vpl.dts | 13 ++
tools/binman/test/204_vpl_bss_pad.dts | 17 ++
40 files changed, 997 insertions(+), 95 deletions(-)
rename doc/{README.SPL => develop/spl.rst} (61%)
create mode 100644 tools/binman/etype/u_boot_vpl.py
create mode 100644 tools/binman/etype/u_boot_vpl_bss_pad.py
create mode 100644 tools/binman/etype/u_boot_vpl_dtb.py
create mode 100644 tools/binman/etype/u_boot_vpl_expanded.py
create mode 100644 tools/binman/etype/u_boot_vpl_nodtb.py
create mode 100644 tools/binman/test/201_u_boot_vpl.dts
create mode 100644 tools/binman/test/202_u_boot_vpl_nodtb.dts
create mode 100644 tools/binman/test/203_fdt_incl_vpl.dts
create mode 100644 tools/binman/test/204_vpl_bss_pad.dts
--
2.32.0.93.g670b81a890-goog
