[PATCH] image: Control FIT signature verification at runtime

[Dhananjay Phadke]

On 2/14/2022 3:13 PM, 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?
> 
>> There's not much case for disabling HW RoT, which implies the bootloader
>> (U-Boot or more) has to be trusted after board is manufactured
>> (OTPstraps, especially OTPCFG0[6], are programmed).
>>
>> There's indeed a case for disabling secure boot on OS FIT image -
> 
> Why wouldn't you want to replace the bootloader just as easily as you can
> replace the kernel / OS itself?  I don't understand why this is more special
> than any other software.  Bootloaders are replaced on "real" systems all the
> time.  There are multiple efforts to be able to replace BIOS/UEFI with a free
> implementation as well.
> 
> I would consider the "HW RoT" to be the software in ROMs and not anything
> which can be replaced, like u-boot.  Why are you extending it to include u-boot?

Agree that ROM maybe just immutable code + some logic, but almost surely
lacks high level stack e.g. network stack to communicate securely and
change boot behavior (remote unlock).

Bootloader (U-Boot in Aspeed case) happens to be the first component
with rich stack to enable such workflows without / before physical
intervention.

It also means, for defense against physical attacks (e.g. replace boot
SPI), first mutable component (bootloader) must be trusted by immutable
component earlier in boot chain. Further secure boot chain may have its
own control knobs from compile or runtime.


> 
>> If bootloader is trusted, it's possible to remotely push the policy to
>> disable runtime FIT image secure boot. Such policy push must use secure
>> transport (someway authenticated) and storage (simplest U-Boot env).
>> This is helpful in cases like booting diagnostic images if board has to
>> be RMA'ed and diagnostic images won't be signed by production keys.
> 
> For second-hand / recycled hardware, I'm not sure the bootloader _is_ trusted.
> It is also possible that I punt on some aspects of supply-chain security and
> simply replace it all when it arrives in my hands.  ie. If I can securely
> replace all the bits, I really don't care if it was tampered with in transit.
> 
>> There's a key-requirement policy already implemented [1].
>>
>> [1]
>> https://lore.kernel.org/u-boot/cover.1597643014.git.thiruan@linux.microsoft.com/
>>
>> Board code can patch "required-policy" = none at runtime based
>> appropriate logic.
>>

[...]

> 
> 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.

I'm supporting idea of having control on FIT verification, just pointed
that it maybe done by board code by just patching U-Boot control FDT,
either the "required-policy" property at /signature or "required"
property in individual key nodes.


Regards,
Dhananjay