Hi Simon Le sam. 13 nov. 2021 à 14:57, Simon Glass <s...@chromium.org> a écrit :
> Hi Heinrich, > > On Sat, 13 Nov 2021 at 04:57, Heinrich Schuchardt <xypron.g...@gmx.de> > wrote: > > > > > > > > On 11/13/21 04:30, Simon Glass wrote: > > > Hi Heinrich, > > > > > > On Fri, 12 Nov 2021 at 17:02, Heinrich Schuchardt <xypron.g...@gmx.de> > wrote: > > >> > > >> > > >> > > >> On 11/12/21 20:49, François Ozog wrote: > > >>> Hi Simon > > >>> > > >>> Le ven. 12 nov. 2021 à 20:36, Simon Glass <s...@chromium.org > > >>> <mailto:s...@chromium.org>> a écrit : > > >>> > > >>> At present mkimage supports signing FITs, the standard U-Boot > image > > >>> type. > > >>> > > >>> Various people are opposed to using FIT since: > > >>> > > >>> just to be sure: I am not one of those. > > >>> > > >>> > > >>> a) it requires adding support for FIT into other bootloaders, > notably > > >>> UEFI > > >>> > > >>> whatever happens to FIT is entirely orthogonal to U-Boot UEFI > subsystem. > > >>> FIT can evolve, U-Boot UEFI does not have to change. > > >> > > >> We already can create signed FIT images containing a UEFI binary and a > > >> devcie-tree and launch the FIT image with the bootm command. > > >> > > >> Cf. > > >> CONFIG_BOOTM_EFI > > >> test/py/tests/test_efi_fit.py > > >> doc/usage/bootefi.rst > > >> > > >> Simon, what are you missing? > > > > > > Some people don't want to use FIT. > > > > The problem with FIT is that other firmware like EDK II does not support > it. > > > > Why do you expect those people to like your new tool better? > > I believe the EDK decision is not so much that it *does* not support > FIT, which is after all not a lot of code, but that it *should* not. > If I have that wrong, please let me know. > UEFI (EDK2 and now U-Boot) design choice is that it does not include *any* technologies for OS: UEFI launches an OS loader that know about those. A possible way to introduce a FIT is by adding a protocol that can register a vendor media file , assign a UUID to a FIT. Add support for this in the UEFI stub of the kernel. Another way would be a minimalistic UEFI app that will fetch the second parameter as a FIT. The FIT format parsing code is only in this minimalistic loader. U-Boot can play this role based on your efforts to have U-Boot as UEFI application. You could also promote FIT in the systemd-boot UeFi application. I believe this is a very good option BTW. > > The goal here is to support signing in an FDT without FIT. I believe > EDK supports FDT, at least. > > > > > > > > >> > > >>> > > >>> > > >>> b) it requires packaging a kernel in this standard U-Boot > format, > > >>> meaning > > >>> that distros must run 'mkimage' and deal with the kernel > and initrd > > >>> being inside a FIT > > >> > > >> U-Boot tools are contained in distros like Debian and Ubuntu. > > >> Package flash-kernel uses a script in /etc/initramfs/post-update.d/ > for > > >> a similar purpose. The same hook directory can be used to create a FIT > > >> image with a simple bash script. > > >> > > >> Why do we need a new tool for signing device-trees? > > >> > > >> The real problem to solve is the protection of the private key used > for > > >> signing any file containing an initrd. > > > > > > Well FIT already solves that one. Either FIT is not being used, in > > > which case this series is useful, or it is being used, in which case > > > the initrd problem is solved. > > > > The question was: > > > > How do you protect the private key used by Linux to sign the FIT image > > with the updated initrd generated by intramfs-tools? > > Well, if it is a FIT we can add a seperate signature at the time the > initramfs-tools runs. It does support multiple signatures. If that is > not suitable I am sure something else can be devised. What are the > constraints / requirements? > > Regards, > Simon > > > > > Best regards > > > > Heinrich > > > > > > > >> > > >>> > > >>> The kernel and initrd can be dealt with in other ways. But > without FIT, > > >> > > >> How can the initrd be checked without FIT? > > > > > > I don't know. Please check with the EFI people. > > > > > >> > > >>> we have no standard way of signing and grouping FDT files. > Instead > > >>> we must > > >>> include them in the distro as separate files. > > >>> > > >>> In particular, some sort of mechanism for verifying FDT files > is needed. > > >>> One option would be to tack a signature on before or after the > file, > > >>> processing it accordingly. But due to the nature of the FDT > binary > > >>> format, > > >>> it is possible to embed a signature inside the FDT itself, > which is very > > >>> convenient. > > >>> > > >>> This series provides a tool, fdt_sign, which can add a > signature to an > > >>> FDT. The signature can be checked later, preventing any change > to > > >>> the FDT, > > >>> other than in permitted nodes (e.g. /chosen). > > >> > > >> I am not aware of any standard defining which nodes may be changed in > > >> the FDT fixup and which may not be changed. > > >> > > >> How can we discover which nodes were excluded from the signature after > > >> the signature? > > > > > > There is no way at present. I decided against adding a list of signed > > > nodes. We can of course add whatever is useful here. > > > > > >> > > >>> > > >>> This series also provides a fdt_check_sign tool, used to check > > >>> signatures. > > >>> > > >>> Both of these tools are stand-alone do not require mkimage or > FIT. > > >>> > > >>> As with FIT signing, multiple signatures are possible, but in > this case > > >>> that requires that fit_sign be called once for each signature. > To > > >>> make the > > >>> check fail if a signature does not match, it should be marked as > > >>> 'required' using the -r flag to fdt_sign. > > >>> > > >>> Run-time support for checking FDT signatures could be added to > U-Boot > > >>> fairly easily, but needs further discussion as the correct > plumbing > > >>> needs > > >>> to be determined. > > >>> > > >>> For now there is absolutely no configurability in the signature > > >>> mechanism. > > >> > > >> I would have expected a description of what a signature looks like. I > > >> don't wont to reverse engineer your patches. > > >> > > >> Please, describe this in doc/develop/ and in this cover-letter. > > > > > > It is the same format as the FIT signature, an RSA signature. See here: > > > > > > > https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L162 > > > > > >> > > >> This series should have been sent as RFC. > > > > > > The last time I did that it disappeared without trace. You can of > > > course make comments on any series I send. > > > > > > Regards, > > > Simon > > > > > >> > > >> Best regards > > >> > > >> Heinrich > > >> > > >>> It would of course be possible to adjust which nodes are > signed, as is > > >>> done for FIT, but that needs further discussion also. The > omission > > >>> of the > > >>> /chosen node is implemented in h_exclude_nodes() like this: > > >>> > > >>> if (type == FDT_IS_NODE) { > > >>> /* Ignore the chosen node as well as /signature and > subnodes */ > > >>> if (!strcmp("/chosen", data) || !strncmp("/signature", > data, 10)) > > >>> return 0; > > >>> } > > >>> > > >>> Man pages are provided with example usage of the tools. Use > this to view > > >>> them: > > >>> > > >>> man -l doc/fdt_check_sign.1 > > >>> > > >>> This series also includes various clean-ups noticed along the > way, > > >>> as well > > >>> as refactoring to avoid code duplication with the new tools. The > > >>> last four > > >>> patches are the new code. > > >>> > > >>> This series is available at u-boot-dm/fdt-sign-working : > > >>> > > >>> > https://source.denx.de/u-boot/custodians/u-boot-dm/-/tree/fdt-sign-working > > >>> < > https://source.denx.de/u-boot/custodians/u-boot-dm/-/tree/fdt-sign-working > > > > >>> > > >>> > > >>> Simon Glass (16): > > >>> rsa: Add debugging for failure cases > > >>> fit_check_sign: Update help to mention the key is in a dtb > > >>> tools: Move copyfile() into a common file > > >>> tools: Avoid leaving extra data at the end of copied files > > >>> tools: Improve comments in signing functions > > >>> tools: Drop unused name in image-host > > >>> tools: Avoid confusion between keys and signatures > > >>> tools: Tidy up argument order in fit_config_check_sig() > > >>> tools: Pass the key blob around > > >>> image: Return destination node for add_verify_data() method > > >>> tools: Pass public-key node through to caller > > >>> tools: mkimage: Show where signatures/keys are written > > >>> tools: Add a new tool to sign FDT blobs > > >>> tools: Add a new tool to check FDT-blob signatures > > >>> test: Add a test for FDT signing > > >>> tools: Add man pages for fdt_sign and fdt_check_sign > > >>> > > >>> MAINTAINERS | 7 + > > >>> boot/image-fit-sig.c | 151 +++++++++---- > > >>> boot/image-fit.c | 12 +- > > >>> common/spl/spl_fit.c | 3 +- > > >>> doc/fdt_check_sign.1 | 74 +++++++ > > >>> doc/fdt_sign.1 | 111 ++++++++++ > > >>> include/image.h | 80 ++++++- > > >>> include/u-boot/ecdsa.h | 5 +- > > >>> include/u-boot/rsa.h | 5 +- > > >>> lib/ecdsa/ecdsa-libcrypto.c | 4 +- > > >>> lib/rsa/rsa-sign.c | 5 +- > > >>> lib/rsa/rsa-verify.c | 13 +- > > >>> test/py/tests/test_fdt_sign.py | 83 ++++++++ > > >>> test/py/tests/test_vboot.py | 21 +- > > >>> test/py/tests/vboot/sign-fdt.dts | 23 ++ > > >>> test/py/tests/vboot_comm.py | 22 ++ > > >>> tools/Makefile | 10 +- > > >>> tools/fdt-host.c | 353 > +++++++++++++++++++++++++++++++ > > >>> tools/fdt_check_sign.c | 85 ++++++++ > > >>> tools/fdt_host.h | 46 ++++ > > >>> tools/fdt_sign.c | 210 ++++++++++++++++++ > > >>> tools/fit_check_sign.c | 4 +- > > >>> tools/fit_common.c | 69 ++++++ > > >>> tools/fit_common.h | 23 ++ > > >>> tools/fit_image.c | 59 +----- > > >>> tools/image-fdt-sig.c | 254 ++++++++++++++++++++++ > > >>> tools/image-host.c | 155 +++++++++++--- > > >>> tools/imagetool.h | 4 + > > >>> tools/mkimage.c | 4 + > > >>> 29 files changed, 1714 insertions(+), 181 deletions(-) > > >>> create mode 100644 doc/fdt_check_sign.1 > > >>> create mode 100644 doc/fdt_sign.1 > > >>> create mode 100644 test/py/tests/test_fdt_sign.py > > >>> create mode 100644 test/py/tests/vboot/sign-fdt.dts > > >>> create mode 100644 test/py/tests/vboot_comm.py > > >>> create mode 100644 tools/fdt-host.c > > >>> create mode 100644 tools/fdt_check_sign.c > > >>> create mode 100644 tools/fdt_sign.c > > >>> create mode 100644 tools/image-fdt-sig.c > > >>> > > >>> -- > > >>> 2.34.0.rc1.387.gb447b232ab-goog > > >>> > > >>> -- > > >>> > > >>> François-Frédéric Ozog | /Director Business Development/ > > >>> T: +33.67221.6485 > > >>> francois.o...@linaro.org <mailto:francois.o...@linaro.org> | Skype: > ffozog > > >>> > > >>> > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
