Comment by jcgl
1 day ago
That does sound better, but haven't you just made the unlocked seconds stage bootloader functionally equivalent to secure boot keys?
Instead of [get released SB keys] -> [boot arbitrary payloads]
It becomes [get unlocked second stage bootloader] -> [boot arbitrary payloads]
Although, I guess that the details matter in terms of the process used to supply OTAs and second stage bootloaders. If changing to the unlocked bootloader requires physical access (or some such thing), then I could see that working.
Is there anything else I'm missing?
Secure boot is desirable for a lot of reasons including design protection (stopping your product being cloned), supply chain security, preventing malicious updates etc.
The question is one of how you can hand control to the user without endangering your legitimate commercial interests as well as the security of the rest of the fleet, exactly how you tackle that will depend on the product.
Don't get me wrong, I like secure boot and securing the boot chain more generally. Was just trying to respond on the merits here.
How would you envision the opt-in process for the unlocked second stage bootloader?