[PATCH] image: Control FIT signature verification at runtime

Andrew Jeffery andrew at aj.id.au
Tue Feb 15 01:21:42 CET 2022

On Tue, 15 Feb 2022, at 09:43, Patrick Williams wrote:
> On Mon, Feb 14, 2022 at 11:14:53AM -0800, Dhananjay Phadke wrote:
>> On 2/13/2022 5:13 PM, Andrew Jeffery wrote:
>> We can decouple HW RoT and runtime control on enforcing secure boot
>> (requiring one or keys) on FIT image. Conflating two raises lot of
>> questions.
> I won't claim to be a security expert but I don't understand this statement.
> What are the "lots of questions" that are raised?

I was trying to avoid derailing the review with this, but here we are.

I have the same question as Patrick. What are your concerns here?

>> > 
>> > With that in mind:
>> > 
>> > To escape the manufacturer's key-chain for owner-controlled signatures
>> > the concept is the manufacturer-signed SPL (or u-boot payload) will load
>> > keys from an external, write-protected EEPROM. These keys are used to
>> > verify the next element of the boot process, providing user control.
>> > 
>> > To configure owner-controlled keys the EEPROM write-protect must be
>> > disabled. This may, for example, be done via a physical jumper. If left
>> > with write-protection disabled the matching public key for the signature
>> > on the payload can arbitrarily be installed into the EEPROM which makes
>> > secure-boot verification moot. The patch avoids the run-around in this
>> > last behaviour by providing a platform hook to read the state of what is
>> > effectively the EEPROM write-protect pin.
> Isn't this jumper proposal just like the TCG Physical Presence requirements?
> This is a software implementation and requires a particular hardware design for
> it to be done right, but it seems to be along the same lines.

Possibly. I'll defer to Chris on that.


More information about the U-Boot mailing list