Hello Alex, Thanks for sharing your thoughts.
On Fri, 3 Sept 2021 at 19:47, Alex G. <mr.nuke...@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
