Hi Thomas and Eden,

On Mon, Aug 12, 2024 at 9:48 AM thomas.gymer--- via OP-TEE < op-tee@lists.trustedfirmware.org> wrote:

Hello all,

We (Eden and I) have been assigned a summer project exploring the possibility of verified boot for Linux with a view to experiment with a TEE, and would like to share our outcomes from the project so far.

We've been working on condensing all the information and documentation on TF-A, OP-TEE, and U-Boot verified boot into a trivially workable form, a Makefile, for the Raspberry Pi 3B+. Our aim is a proof of concept pilot project to see what parts of the technology outlined in the NIST standards for secure boot on IoT is currently available, and thus what needs to be developed. This also leads us to an interest in full crypto algorithm agility to ensure quick adoption of the quantum safe algorithms as they come out. I should note that our boot order here is TF-A to OP-TEE, then TF-A to U-Boot to Linux. This has raised a few areas of note and a couple of issues on our end:

# Areas of note

• U-Boot and Linux DTB's being incompatible has minimal documentation

Newer versions of U-Boot do have `CONFIG_OF_UPSTREAM`, but I can't see that as a recommended solution. Perhaps a note in the Kconfig entry for `CONFIG_OF_CONTROL` would be sufficient

• U-Boot can fail silently if the DTB used is incompatible

No idea what the solution here could be; an invalid DTB inevitably means that the firmware cannot access any of the hardware correctly.

• U-Boot unable to find `CONFIG_OF_SEPARATE` DTB's when loaded by TF-A;

this is a TF-A problem, but maybe check other possible places for a DTB on the U-Boot end?

• U-Boot itself appears to have good crypto agility (or will in the near

future), with a macro and existing algorithms as examples for the addition of new algorithms

• `mkimage` appears to be lacking these same features for crypto agility,

which would otherwise set U-Boot up to be ready for the new quantum safe algorithms' release A similar macro system for `mkimage`, or some other schema for defining how to add algorithm keys to the FDT, would provide some amazing flexibility, already being able to define more than one signature as required. Adding keys to the FDT would need to be standardised in someway for this, I would imagine.

As a general comment, the incompatibilities (DTB UBoot/Linux) you've seen is well known to the community and it's been a long running effort to improve the situation.

I am very aware that some of the below issues are not relevant to all projects, but thought it best to maintain a single list to ensure that the correct place to make a fix for each issue is not locked project wise too early. # Issues

• buildroot build fails when the directory length is greater than ~80

characters

Interesting, I wasn't aware.

• TF-A does not pass on the DTB address unless `RPI3_DIRECT_LINUX_BOOT` is

set, which also implies a define U-Boot doesn't need

• TF-A `LOG_LEVEL=50` flag has compatibility issue in xlat tables v2 when

compiled for 64bit

I believe this one is about the image becoming too big? Or is it actually a xlat tables issue?

• `mkimage` ECDSA key adding to FDT fails if there is no signature node

pre-added and doesn't set `required` node when `-r` is used

• `fit_check_sig`fails to check an ECDSA signed FIT file with

corresponding FDT due to `<null>` hash node

• `mkimage` expects ECDSA private key only in a `.pem` and not `.der`,

which would be standard for a single private key

We intend to release the Makefile and accompanying scripts for this on Monday 12th August, likely ~5pm BST to give us time to finalise what we have currently; this will consist of two Makefiles: one for verified boot using `CONFIG_OF_EMBED`, and another using `CONFIG_OF_SEPARATE` on U-Boot v2024.07. We are currently planning on releasing this on GitHub under the same license as the involved projects, but what would be the most helpful way for us to release this to you?

As one of the maintainers of the OP-TEE project, I'm always in favor of having changes done in the official repositories, both code and documentation. There is nothing wrong with doing a write up and keep fixes elsewhere as such, but it has happened a couple of times that when people do these things on their own, other people find the instructions etc on internet and when they don't get it to work, they post issues and questions at the official OP-TEE issue list. However, since this is code not maintained or in the official git, there is little we can do about it. So, if you can send fixes upstream to the official projects, that's what I would suggest, that's the best in the long run. If you keep it elsewhere, may I please just ask you to put some note somewhere in the docs or readme, saying that this is work done outside official code, so if people try it and if it for some reason wouldn't work, then asking for help upstream likely won't lead to anything.

We have, beside the points raised in the Issues section above, no specific changes for the exiting repos, focusing instead on Makefiles which pull together parts of the existing releases to produce a working PoC as quickly as possible. We intend to also release this to the Raspberry Pi community as a TEE solution they can experiment with today.

I understand that you have a deadline for a summer project and therefore have to prioritize and make decisions. It looks like you've done a great deep dive and found various things that can (and should) be improved. For OP-TEE, if you have time, please consider sending your findings to the various "Issues" list at GitHub. If there is no obvious place to post the issue, you can use the one in OP-TEE os ( https://github.com/OP-TEE/optee_os/issues). For U-Boot I believe it's the mailinglist that is the best place to discuss individual issues.

This email has been sent to:

• u-boot@lists.denx.de
• op-tee@lists.trustedfirmware.org

and the Makefiles will be sent to Raspberry Pi Foundation and community some point next week

Thomas Gymer (thomas.gymer@bt.com) & Eden Hamilton (eden.hamilton@bt.com)