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. 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.
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 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.
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.
Let's get serious. Without SPL, I wouldn't have been able to boot linux in one second, with a secure OS.
Alex