Hi Jan
On Tue, 9 Nov 2021 at 13:58, Jan Kiszka jan.kiszka@siemens.com wrote:
On 09.11.21 13:43, François Ozog wrote:
Hi
as we are in design discussions, I would promote the idea of not pushing non hardware related things in the DTB that is passed to the kernel.
This was never proposed. The public keys go into the *control* FDTs.
great ;-)
Is your use case to allow U-Boot to verify the kernel's signature ? Why not putting it into an environment variable?
This is both about validating OS FIT containers as well as SPL checking U-Boot proper before continuing the boot there. The former case can be replaced with UEFI logic and likely taking the key from TEE (we do that as well in first prototypes), but the latter can't (yet).
If your use case is on Arm or RISC-V, both environments are working heavily to make https://arm-software.github.io/ebbr/ https://arm-software.github.io/ebbr/ standard available on a large number of boards. This offers UEFI interface and SecureBoot (and later MeasuredBoot) services. For Arm boards just check for SystemReady compliance. In this context, traditional UEFI secure variables are used to deal with certificates and hashes: PK, KEK, db... You can obviously do differently but you will be on your own to extend the chain of trust to IMA, secure containers (rooted down to hRoT) and other security facilities in the Linux side. Could you describe your use case in more details?
doc/uImage.FIT/signature.txt ;)
More concrete: We are currently massaging board/siemens/iot2050 to close its static chain of trust between SPL and U-Boot main, using software means (vendor means do not work because FSBL key != TF-A/TEE/U-Boot key).
And will the chain of trust be continuous or with a very brief breakage
with this approach? I other words, can you enroll the TF-A/TEE/U-Boot key so that it can be trusted by FSBL key?
Jan
On Tue, 9 Nov 2021 at 11:07, Jan Kiszka <jan.kiszka@siemens.com mailto:jan.kiszka@siemens.com> wrote:
On 09.11.21 10:37, Roman Kopytin wrote: > Can we have discussion with code lines? For me it is not very clear, because it isn't my code. > Please do not top-post. > -----Original Message----- > From: Jan Kiszka <jan.kiszka@siemens.com <mailto:jan.kiszka@siemens.com>> > Sent: Tuesday, November 9, 2021 12:17 PM > To: Roman Kopytin <Roman.Kopytin@kaspersky.com <mailto:Roman.Kopytin@kaspersky.com>>; u-boot@lists.denx.de <mailto:u-boot@lists.denx.de>; Rasmus Villemoes <rasmus.villemoes@prevas.dk <mailto:rasmus.villemoes@prevas.dk>> > Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool > > On 08.11.21 16:28, Roman Kopytin wrote: >> In order to reduce the coupling between building the kernel and >> U-Boot, I'd like a tool that can add a public key to U-Boot's dtb >> without simultaneously signing a FIT image. That tool doesn't seem to >> exist, so I stole the necessary pieces from mkimage et al and putit
>> in a single .c file. >> >> I'm still working on the details of my proposed "require just kout
>> these n required keys" and how it should be implemented, but itwill
>> probably involve teaching this tool a bunch of new options. These >> patches are not necessarily ready for inclusion (unless someoneelse
>> finds fdt_add_pubkey useful as is), but I thought I might as well send >> it out for early comments. > > I'd also like to see the usage of this hooked into the buildprocess.
> > And to my understanding of [1], that approach will provide a feature that permits hooking with the build but would expect the key as dtsi fragment. Can we consolidate the approaches? > > My current vision of a user interface would be a Kconfig option that takes a list of key files to be injected. Maybe make that three lists, one for "required=image", one for "required=conf", and one for optional keys (if that has a use case in practice, no idea). > > Jan > > [1] >https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prev...
<https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prev...
> > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > For what would you like to have code? The kconfig addition? diff --git a/common/Kconfig.boot b/common/Kconfig.boot index d3a12be228..a9ed4d4ec4 100644 --- a/common/Kconfig.boot +++ b/common/Kconfig.boot @@ -279,6 +279,14 @@ config SPL_FIT_GENERATOR endif # SPL +config FIT_SIGNATURE_PUB_KEYS + string "Public keys to use for FIT image verification" + depends on FIT_SIGNATURE || SPL_FIT_SIGNATURE + help + Public keys, or certificate files to extract them from, that shall + be used to verify signed FIT images. The keys will be embedded into + the control device tree of U-Boot. + endif # FIT config LEGACY_IMAGE_FORMAT But note that we are in a design discussion here, and I'm at least reluctant to code up n-versions without having some common idea where things should move. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux--
François-Frédéric Ozog | /Director Business Development/ T: +33.67221.6485 francois.ozog@linaro.org <mailto:francois.ozog@linaro.org | Skype: ffozog
-- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux