[U-Boot] [PATCH] verified-boot: Minimal support for booting U-Boot proper from SPL
Sumit Garg
sumit.garg at nxp.com
Mon Jun 6 06:05:33 CEST 2016
> -----Original Message-----
> From: Teddy Reed [mailto:teddy.reed at gmail.com]
> Sent: Monday, June 06, 2016 2:58 AM
> To: Sumit Garg <sumit.garg at nxp.com>
> Cc: sjg at chromium.org; dannenberg at ti.com; u-boot at lists.denx.de; Ruchika
> Gupta <ruchika.gupta at nxp.com>; Aneesh Bansal <aneesh.bansal at nxp.com>;
> york sun <york.sun at nxp.com>
> Subject: Re: [PATCH] verified-boot: Minimal support for booting U-Boot proper
> from SPL
>
> On Wed, Jun 1, 2016 at 9:40 PM, Sumit Garg <sumit.garg at nxp.com> wrote:
> >> -----Original Message-----
> >> From: Teddy Reed [mailto:teddy.reed at gmail.com]
> >> Sent: Tuesday, May 31, 2016 2:23 AM
> >> To: Sumit Garg <sumit.garg at nxp.com>
> >> Cc: sjg at chromium.org; dannenberg at ti.com; u-boot at lists.denx.de;
> >> Ruchika Gupta <ruchika.gupta at nxp.com>; Aneesh Bansal
> >> <aneesh.bansal at nxp.com>
> >> Subject: Re: [PATCH] verified-boot: Minimal support for booting
> >> U-Boot proper from SPL
> >>
> >> Hi Sumit!
> >>
> >> On Sun, May 29, 2016 at 10:32 PM, Sumit Garg <sumit.garg at nxp.com>
> wrote:
> >> > Can you make this support more generic as you have used only
> >> CONFIG_SPL_FIT_SIGNATURE for SPL verified boot while our platforms
> >> doesn't use fit signature approach for verification?
> >> >
> >>
> >> CONFIG_SPL_FIT_SIGNATURE only adds ./lib/rsa/rsa-{checksum,verify}.c
> >>
> >> And the only related change is to mimic the existing
> >> CONFIG_FIT_SIGNATURE option.
> >>
> >> This patch only allows an SPL to include the verified boot
> >> implementation from U-Boot proper. I would like to keep it as simple and
> concise as possible.
> >>
> >> Generalizing the various verified/secure boot methods that exist
> >> within U-Boot would be a much larger effort. :)
> >>
> >> > May be you can use CONFIG_SPL_VERIFIED_BOOT?
> >> >
> >>
> >> In your previous proposed patch [1], I don't see anything modifying
> >> ./lib/rsa/rsa-{checksum,verify}.c. The patch does include the
> >> ./lib/rsa directory outside of the non-SPL build, but that is not
> >> enough to add the RSA verify and checksum implementationd. I believe
> >> your affected boards will still need CONFIG_FIT_SIGNATURE.
> >>
> >> Are you suggesting we should rename CONFIG_FIT_SIGNATURE to
> >> CONFIG_SPL_VERIFIED_BOOT? :)
> >>
> >> If that's the case, this patch is NOT the place to perform that
> refactor/rename.
> >> Since that will also need to update tooling, build configs, the
> >> existing U-Boot proper verified boot documentation, and several board
> >> configurations. It will also render quite a few guides/walkthroughs
> >> obsolete so broader communication may be needed.
> >
> > Yeah you are correct this patch is not meant for refactoring. So
> > rather I will define only CONFIG_SPL_CRYPTO_SUPPORT, CONFIG_SPL_RSA
> &
> > CONFIG_SPL_HASH_SUPPORT for our platform and skip
> CONFIG_SPL_FIT_SIGNATURE.
> >
>
> Ok, sounds like a plan. :)
>
> >>
> >> [1] http://lists.denx.de/pipermail/u-boot/2016-May/256133.html
> >>
> >> >> -----Original Message-----
> >> >> From: Teddy Reed [mailto:teddy.reed at gmail.com]
> >> >> Sent: Sunday, May 29, 2016 7:28 AM
> >> >> To: u-boot at lists.denx.de
> >> >> Cc: sjg at chromium.org; dannenberg at ti.com; Sumit Garg
> >> >> <sumit.garg at nxp.com>
> >> >> Subject: [PATCH] verified-boot: Minimal support for booting U-Boot
> >> >> proper from SPL
> >> >>
> >> >> This allows a board to configure verified boot within the SPL
> >> >> using a FIT or FIT with external data. It also allows the SPL to
> >> >> perform signature verification without needing relocation.
> >> >>
> >> >> The board configuration will need to add the following feature defines:
> >> >> CONFIG_SPL_CRYPTO_SUPPORT
> >> >> CONFIG_SPL_HASH_SUPPORT
> >> >> CONFIG_SPL_SHA256
> >> >>
> >> >> In this example, SHA256 is the only selected hashing algorithm.
> >> >>
> >> >> And the following booleans:
> >> >> CONFIG_SPL=y
> >> >> CONFIG_SPL_DM=y
> >> >> CONFIG_SPL_LOAD_FIT=y
> >> >> CONFIG_SPL_FIT=y
> >> >> CONFIG_SPL_OF_CONTROL=y
> >> >> CONFIG_SPL_OF_LIBFDT=y
> >> >> CONFIG_SPL_FIT_SIGNATURE=y
> >> >>
> >> >> Signed-off-by: Teddy Reed <teddy.reed at gmail.com>
> >> >> Cc: Simon Glass <sjg at chromium.org>
> >> >> Cc: Andreas Dannenberg <dannenberg at ti.com>
> >> >> ---
> >> >> Kconfig | 11 +++++++++++
> >> >> common/Makefile | 1 +
> >> >> drivers/Makefile | 1 +
> >> >> drivers/crypto/rsa_mod_exp/mod_exp_sw.c | 1 +
> >> >> lib/Makefile | 9 ++++-----
> >> >> lib/rsa/Kconfig | 4 ++++
> >> >> lib/rsa/Makefile | 2 +-
> >> >> 7 files changed, 23 insertions(+), 6 deletions(-)
> >> >>
> >> >> diff --git a/Kconfig b/Kconfig
> >> >> index 4b46216..817f4f0 100644
> >> >> --- a/Kconfig
> >> >> +++ b/Kconfig
> >> >> @@ -183,6 +183,11 @@ config FIT
> >> >> verified boot (secure boot using RSA). This option enables that
> >> >> feature.
> >> >>
> >> >> +config SPL_FIT
> >> >> + bool "Support Flattened Image Tree within SPL"
> >> >> + depends on FIT
> >> >> + depends on SPL
> >> >> +
> >> >> config FIT_VERBOSE
> >> >> bool "Display verbose messages on FIT boot"
> >> >> depends on FIT
> >> >> @@ -205,6 +210,12 @@ config FIT_SIGNATURE
> >> >> format support in this case, enable it using
> >> >> CONFIG_IMAGE_FORMAT_LEGACY.
> >> >>
> >> >> +config SPL_FIT_SIGNATURE
> >> >> + bool "Enable signature verification of FIT firmware within SPL"
> >> >> + depends on SPL_FIT
> >> >> + depends on SPL_DM
> >> >> + select SPL_RSA
> >> >> +
> >> >> config FIT_BEST_MATCH
> >> >> bool "Select the best match for the kernel device tree"
> >> >> depends on FIT
> >> >> diff --git a/common/Makefile b/common/Makefile index
> >> >> 0562d5c..e6b0c22
> >> >> 100644
> >> >> --- a/common/Makefile
> >> >> +++ b/common/Makefile
> >> >> @@ -93,6 +93,7 @@ obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
> endif #
> >> >> !CONFIG_SPL_BUILD
> >> >>
> >> >> ifdef CONFIG_SPL_BUILD
> >> >> +obj-$(CONFIG_SPL_HASH_SUPPORT) += hash.o
> >> >> obj-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
> >> >> obj-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o
> >> >> obj-$(CONFIG_SPL_NET_SUPPORT) += miiphyutil.o diff --git
> >> >> a/drivers/Makefile b/drivers/Makefile index 99dd07f..772d437
> >> >> 100644
> >> >> --- a/drivers/Makefile
> >> >> +++ b/drivers/Makefile
> >> >> @@ -10,6 +10,7 @@ obj-$(CONFIG_$(SPL_)RAM) += ram/
> >> >>
> >> >> ifdef CONFIG_SPL_BUILD
> >> >>
> >> >> +obj-$(CONFIG_SPL_CRYPTO_SUPPORT) += crypto/
> >> >> obj-$(CONFIG_SPL_I2C_SUPPORT) += i2c/
> >> >> obj-$(CONFIG_SPL_GPIO_SUPPORT) += gpio/
> >> >> obj-$(CONFIG_SPL_MMC_SUPPORT) += mmc/ diff --git
> >> >> a/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
> >> >> b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
> >> >> index dc6c064..3817fb3 100644
> >> >> --- a/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
> >> >> +++ b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
> >> >> @@ -32,6 +32,7 @@ U_BOOT_DRIVER(mod_exp_sw) = {
> >> >> .name = "mod_exp_sw",
> >> >> .id = UCLASS_MOD_EXP,
> >> >> .ops = &mod_exp_ops_sw,
> >> >> + .flags = DM_FLAG_PRE_RELOC,
> >> >> };
> >> >>
> >> >> U_BOOT_DEVICE(mod_exp_sw) = {
> >> >> diff --git a/lib/Makefile b/lib/Makefile index 02dfa29..0df5395
> >> >> 100644
> >> >> --- a/lib/Makefile
> >> >> +++ b/lib/Makefile
> >> >> @@ -9,7 +9,6 @@ ifndef CONFIG_SPL_BUILD
> >> >>
> >> >> obj-$(CONFIG_EFI) += efi/
> >> >> obj-$(CONFIG_EFI_LOADER) += efi_loader/
> >> >> -obj-$(CONFIG_RSA) += rsa/
> >> >> obj-$(CONFIG_LZMA) += lzma/
> >> >> obj-$(CONFIG_LZO) += lzo/
> >> >> obj-$(CONFIG_ZLIB) += zlib/
> >> >> @@ -25,8 +24,6 @@ obj-y += crc8.o
> >> >> obj-y += crc16.o
> >> >> obj-$(CONFIG_ERRNO_STR) += errno_str.o
> >> >> obj-$(CONFIG_FIT) += fdtdec_common.o
> >> >> -obj-$(CONFIG_$(SPL_)OF_CONTROL) += fdtdec_common.o
> >> >> -obj-$(CONFIG_$(SPL_)OF_CONTROL) += fdtdec.o
> >> >> obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
> >> >> obj-$(CONFIG_GZIP) += gunzip.o
> >> >> obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o @@ -39,9 +36,7 @@ obj-y
> >> >> += net_utils.o
> >> >> obj-$(CONFIG_PHYSMEM) += physmem.o obj-y += qsort.o obj-y +=
> >> >> rc4.o
> >> >> -obj-$(CONFIG_SHA1) += sha1.o
> >> >> obj-$(CONFIG_SUPPORT_EMMC_RPMB) += sha256.o
> >> >> -obj-$(CONFIG_SHA256) += sha256.o
> >> >> obj-y += strmhz.o
> >> >> obj-$(CONFIG_TPM) += tpm.o
> >> >> obj-$(CONFIG_RBTREE) += rbtree.o
> >> >> @@ -49,6 +44,10 @@ obj-$(CONFIG_BITREVERSE) += bitrev.o obj-y +=
> >> >> list_sort.o endif
> >> >>
> >> >> +obj-$(CONFIG_$(SPL_)RSA) += rsa/
> >> >> +obj-$(CONFIG_$(SPL_)SHA1) += sha1.o
> >> >> +obj-$(CONFIG_$(SPL_)SHA256) += sha256.o
> >> >> +
> >> >> obj-$(CONFIG_$(SPL_)OF_LIBFDT) += libfdt/ ifdef
> >> >> CONFIG_SPL_OF_CONTROL
> >> >> obj-$(CONFIG_OF_LIBFDT) += libfdt/ diff --git a/lib/rsa/Kconfig
> >> >> b/lib/rsa/Kconfig index 86df0a0..09ec358
> >> >> 100644
> >> >> --- a/lib/rsa/Kconfig
> >> >> +++ b/lib/rsa/Kconfig
> >> >> @@ -13,6 +13,10 @@ config RSA
> >> >> option. The software based modular exponentiation is built into
> >> >> mkimage irrespective of this option.
> >> >>
> >> >> +config SPL_RSA
> >> >> + bool "Use RSA Library within SPL"
> >> >> + depends on RSA
> >> >> +
> >> >> if RSA
> >> >> config RSA_SOFTWARE_EXP
> >> >> bool "Enable driver for RSA Modular Exponentiation in software"
> >> >> diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile index
> >> >> 6867e50..4b2c1ba 100644
> >> >> --- a/lib/rsa/Makefile
> >> >> +++ b/lib/rsa/Makefile
> >> >> @@ -7,5 +7,5 @@
> >> >> # SPDX-License-Identifier: GPL-2.0+
> >> >> #
> >> >>
> >> >> -obj-$(CONFIG_FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o
> >> >> +obj-$(CONFIG_$(SPL_)FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o
> >> >> obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o
> >> >> --
> >> >> 2.7.4
> >>
> >>
> >> Take care!
> >> --
> >> Teddy Reed V
> >
> > Sorry for late response. I will try to rebase my patches using this
> > patch. Also let me know should I send those patches in parallel with
> > this patch or wait for acceptance of this patch?
>
> Either way, I think a rebase will not have any dependencies (ideally), but you
> also wont have any verified boot in SPL until [1] lands. :)
>
> I have not seen any changes/clarifications requested. And I think Simon usually
> pulls in verified boot changes into his custodian -fdt tree. But I am very new to
> U-Boot development.
>
> [1] https://patchwork.ozlabs.org/patch/627664/
>
> --
> Teddy Reed V
York
Can you accept this patch in your tree as my other patches [1] and [2] have
dependency on this patch?
[1] https://patchwork.ozlabs.org/patch/628987/
[2] https://patchwork.ozlabs.org/patch/628971/
Sumit Garg
More information about the U-Boot
mailing list