Hello Alex,
Thanks for sharing your thoughts.
On Fri, 3 Sept 2021 at 19:47, Alex G. mr.nuke.me@gmail.com wrote:
On 9/3/21 10:32 AM, Marek Vasut wrote:
On 9/1/21 11:07 AM, Patrick DELAUNAY wrote:
On 8/31/21 6:42 PM, Marek Vasut wrote:
I would argue that the U-Boot crypto code went through multiple >> independent security reviews, personally I trust that more than code fully controlled and maintained by any one single company, so I am not buying the security constraint argument here.
When I talk about security, it is not crypto code, but some security features as isolation between cortex A and Cortex M, key infractructure, trusted environment execution, secure update.
I'll offload this answer to Alexandru, however as far as I can tell, SPL is perfectly capable of starting the TEE and setting up the correct execution levels etc. too.
There is not a unisex size for security. It's all driven by requirements.
I fully agree.
My client wants certain pieces of code to be triple-encrypted with a full-body latex suit (and kevlar reinforced). I don't care about A and M separation, clock control and other fancies. In fact it's better that those are handled by linux because that helps with boot time, considerably.
I can achieve that by ECDSA-signing the FSBL, and putting that critical code in TEE trusted applications. I don't need to TiVO-ize the device, lock the kernel, etc. Because of that, can incorporate GPL-v3 programs and libraries, and generally have more flexibility in the software architecture.
TF-A sources are available on the web. You can fetch them, and even incorporate GPL source, provided you comply with the terms. I must admit that upstream changes incorporating GPL code will likely be quite discussed.
I'm more than happy to deal with the TZC and ETZPC in SPL, because SPL is fast. Again, this is really driven by the totality of requirements.
TF-A is a pretty poor solution in this case for a trio of reasons. When I was trying TF-A, I found a small bug in assembly code. I tried to submit a fix, which was immediately rejected. I was required to sign a CLA granting patent rights. I can't do that legally on behalf of my client. This puts TF-A on a take it or leave it basis, such that I can't
True, at the time it was not handy to contribute. TF-A now relies on Developer's Certificate of Origin 1.1. So anyone can post a change proposal. It's true that the review process is less flexible than the well established U-Boot ML.
fix problems with it.
TF-A also requires me to use a new file format (FIP). It's a binary format which is already a huge red flag for me. It seems very similar to a concatenation of EFI HOBs and FFS, and it makes no sense why TF-A would not have just gone with those more established formats. Is it secure? I don't know. It's pretty new to start with, and much more inflexible than FIT. Why would I recommend to my client an unproven format, when FIT has already gone through several CVEs and is more widely supported? Definitely not.
Then TF-A is one extra codebase in the secure path of the system. Do I want to have to deal with an extra program bringing its own possible flaws on holes? Not really.
On 64bit, the system needs TF-A as secure monitor (BL31) so TF-A package is already part of the system build for these. TF-A also boots platforms that do not use U-Boot in the boot sequence. For them, adding SPL would be adding a extra codebase.
The official STM wiki seems to document the "how" of security: "Use TF-A and TEE, all others unsupported". It doesn't explain the "why". The "how" is what my client complained it takes two minutes to boot. And those two minutes are the reason I'm working on this.
It would help to have better explained options with their corresponding security implications. Even absent that, SPL is perfectly capable of starting a secure system. I think it's also more flexible.
I agree SPL could be used in place of TF-A BL2, if one prefers this one over that one. SPL would need to pass a few boot information to secure world firmware image (TF-A BL31), as those TF-A BL2 passes to it's BL31 stage. as those SPL passes the U-Boot proper :)
regards, etienne
Let's get serious. Without SPL, I wouldn't have been able to boot linux in one second, with a secure OS.
Alex