From: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> To: openembedded-core@lists.openembedded.org Cc: andrew@aj.id.au, Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>, openbmc@lists.ozlabs.org Subject: [PATCH 0/4] u-boot: Support for SPL verified boot Date: Mon, 15 Mar 2021 13:58:02 -0300 [thread overview] Message-ID: <20210315165806.1633-1-klaus@linux.vnet.ibm.com> (raw) This patch series aims at extending U-Boot's verified boot support to also include SPL. Presently, setting UBOOT_SIGN_ENABLE instructs the classes uboot-sign and kernel-fitimage to create and sign a Linux Kernel fitImage. This proposal introduces the variable SPL_SIGN_ENABLE that aims at (re-) creating the U-Boot (proper) uImage fitImage and signing it. In order to accomplish this, the first patch moves some of necessary infrastructure (variables, functions) used to sign the Kernel fitImage to more common locations, and then essentially duplicates the method currently used to sign the Kernel fitImage to also sign the U-Boot fitImage. In the UBOOT_SIGN_ENABLE = "1" scenario, nothing really changes: The Kernel fitImage is created, then signed, and the pubkey is added to u-boot.dtb which is concatenated with the u-boot-nodtb.bin to create the u-boot final image. In case SPL_SIGN_ENABLE = "1", The U-Boot PN will take care of (re-) creating the U-Boot fitImage (using custom .its script) after compile, sign it, and contatenate the u-boot-spl.dtb (with the public key) with u-boot-spl-nodtb.bin to create the final U-Boot SPl on deploy. In case both UBOOT_SIGN_ENABLE and SPL_SIGN_ENABLE are set, the Kernel PN will take care of creating and signing the U-Boot fitImage (becase we need to also sign the FDT image containing the Kernel pubkey), and take care of deploying it. One caveat is that when moving between the scenarios above, the user might need to remove the tmp/ directory, since there could be a collision for some of the files deployed into the images directory, since the configuration may determine which PN does that. I added oe-selftest testcases and also tested this on upstream OpenBMC with AST2600 BMC devices. meta/classes/kernel-fitimage.bbclass | 69 +++------------- meta/classes/uboot-config.bbclass | 58 +++++++++++++ meta/classes/uboot-sign.bbclass | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- meta/lib/oeqa/selftest/cases/fitimage.py | 293 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ meta/recipes-bsp/u-boot/u-boot.inc | 46 ----------- 5 files changed, 736 insertions(+), 125 deletions(-) Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
WARNING: multiple messages have this Message-ID (diff)
From: "Klaus Heinrich Kiwi" <klaus@linux.vnet.ibm.com> To: openembedded-core@lists.openembedded.org Cc: joel@jms.id.au, andrew@aj.id.au, openbmc@lists.ozlabs.org, Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> Subject: [PATCH 0/4] u-boot: Support for SPL verified boot Date: Mon, 15 Mar 2021 13:58:02 -0300 [thread overview] Message-ID: <20210315165806.1633-1-klaus@linux.vnet.ibm.com> (raw) This patch series aims at extending U-Boot's verified boot support to also include SPL. Presently, setting UBOOT_SIGN_ENABLE instructs the classes uboot-sign and kernel-fitimage to create and sign a Linux Kernel fitImage. This proposal introduces the variable SPL_SIGN_ENABLE that aims at (re-) creating the U-Boot (proper) uImage fitImage and signing it. In order to accomplish this, the first patch moves some of necessary infrastructure (variables, functions) used to sign the Kernel fitImage to more common locations, and then essentially duplicates the method currently used to sign the Kernel fitImage to also sign the U-Boot fitImage. In the UBOOT_SIGN_ENABLE = "1" scenario, nothing really changes: The Kernel fitImage is created, then signed, and the pubkey is added to u-boot.dtb which is concatenated with the u-boot-nodtb.bin to create the u-boot final image. In case SPL_SIGN_ENABLE = "1", The U-Boot PN will take care of (re-) creating the U-Boot fitImage (using custom .its script) after compile, sign it, and contatenate the u-boot-spl.dtb (with the public key) with u-boot-spl-nodtb.bin to create the final U-Boot SPl on deploy. In case both UBOOT_SIGN_ENABLE and SPL_SIGN_ENABLE are set, the Kernel PN will take care of creating and signing the U-Boot fitImage (becase we need to also sign the FDT image containing the Kernel pubkey), and take care of deploying it. One caveat is that when moving between the scenarios above, the user might need to remove the tmp/ directory, since there could be a collision for some of the files deployed into the images directory, since the configuration may determine which PN does that. I added oe-selftest testcases and also tested this on upstream OpenBMC with AST2600 BMC devices. meta/classes/kernel-fitimage.bbclass | 69 +++------------- meta/classes/uboot-config.bbclass | 58 +++++++++++++ meta/classes/uboot-sign.bbclass | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- meta/lib/oeqa/selftest/cases/fitimage.py | 293 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ meta/recipes-bsp/u-boot/u-boot.inc | 46 ----------- 5 files changed, 736 insertions(+), 125 deletions(-) Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
next reply other threads:[~2021-03-15 16:58 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-15 16:58 Klaus Heinrich Kiwi [this message] 2021-03-15 16:58 ` [PATCH 0/4] u-boot: Support for SPL verified boot Klaus Heinrich Kiwi 2021-03-15 16:58 ` [PATCH 1/4] u-boot: Move definitions to common locations Klaus Heinrich Kiwi 2021-03-15 16:58 ` Klaus Heinrich Kiwi 2021-03-15 16:58 ` [PATCH 2/4] u-boot: Add infrastructure to SPL verified boot Klaus Heinrich Kiwi 2021-03-15 16:58 ` Klaus Heinrich Kiwi 2021-03-15 16:58 ` [PATCH 3/4] u-boot: Use a different Key for SPL signing Klaus Heinrich Kiwi 2021-03-15 16:58 ` Klaus Heinrich Kiwi 2021-03-15 16:58 ` [PATCH 4/4] oe-selftest: Add U-Boot fitImage signing testcases Klaus Heinrich Kiwi 2021-03-15 16:58 ` Klaus Heinrich Kiwi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210315165806.1633-1-klaus@linux.vnet.ibm.com \ --to=klaus@linux.vnet.ibm.com \ --cc=andrew@aj.id.au \ --cc=openbmc@lists.ozlabs.org \ --cc=openembedded-core@lists.openembedded.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.