All these points are very true; chains like these are unfortunately based on a root of implicit trust.
I make some counter-arguments:
Secure boot forms the trust basis that the device is definitively running the code you put on it without modification, so is arguably the most security-sensitive aspect of the system, in some ways more critically so than the kernel, network-facing daemons, etc. It is at least as important as those components.
I'm confident a publicly-auditable open-source secure boot implementation would attract fairly reasonable academic interest from the security field and be hacked on (from theoretical design down to implementational edge cases) by the community until it was very very good.
That would help avoid this sort of thing - http://www.cnx-software.com/2016/10/06/hacking-arm-trustzone... - which is currently only an issue because vendor engineering teams are not perfect and there's no widespread collaboration. (There is, of course, also the likely truth that there are similar "vulnerabilities" in all commercial secure boot implementations. Think TSA007.)
The one issue I will acknowledge is that if such a reference design existed and was widely implemented, it would be a very good question as to which manufacturers had "accidents" in the manufacturing process near the secure-boot areas of the chips.
If I understand correctly, the other very major issue (which is kind of really ironic considering what I've just said) is that you have to sign NDAs to understand how the implementation works, and AFAIK even to just use it. So I (a random tinkerer) can't configure a "really trustworthily secure" Linux system, only a major manufacturer/system integrator/etc can. I understand this situation but from the standpoint of paranoid individual security it's crazy - security by obscurity, anyone?
If it is possible for me to play with OTP on iMX from a hobbyist perspective without shelling out for some NDA'd SDK, I'm tentatively interested for what it's worth.
Boot documentation is chapter 7. References "high assurance boot" functionality in the onboard boot ROM, but doesn't give out docs for the ROM. On the other hand, it's not a large ROM so you could just dump and reverse-engineer it.
Interesting... but I find it really amusing that my propositions are to reverse-engineer the secure boot system in order to take advantage of it, and also the fact that the reverse-engineering process won't be that hard. For what I assume is a security-by-obscurity design... reverse-engineering should by definition be really hard I would think, at least at face value.
I make some counter-arguments:
Secure boot forms the trust basis that the device is definitively running the code you put on it without modification, so is arguably the most security-sensitive aspect of the system, in some ways more critically so than the kernel, network-facing daemons, etc. It is at least as important as those components.
I'm confident a publicly-auditable open-source secure boot implementation would attract fairly reasonable academic interest from the security field and be hacked on (from theoretical design down to implementational edge cases) by the community until it was very very good.
That would help avoid this sort of thing - http://www.cnx-software.com/2016/10/06/hacking-arm-trustzone... - which is currently only an issue because vendor engineering teams are not perfect and there's no widespread collaboration. (There is, of course, also the likely truth that there are similar "vulnerabilities" in all commercial secure boot implementations. Think TSA007.)
The one issue I will acknowledge is that if such a reference design existed and was widely implemented, it would be a very good question as to which manufacturers had "accidents" in the manufacturing process near the secure-boot areas of the chips.
If I understand correctly, the other very major issue (which is kind of really ironic considering what I've just said) is that you have to sign NDAs to understand how the implementation works, and AFAIK even to just use it. So I (a random tinkerer) can't configure a "really trustworthily secure" Linux system, only a major manufacturer/system integrator/etc can. I understand this situation but from the standpoint of paranoid individual security it's crazy - security by obscurity, anyone?
If it is possible for me to play with OTP on iMX from a hobbyist perspective without shelling out for some NDA'd SDK, I'm tentatively interested for what it's worth.