[PATCH] image: Control FIT signature verification at runtime
Andrew Jeffery
andrew at aj.id.au
Mon Feb 28 12:29:02 AEDT 2022
On Tue, 15 Feb 2022, at 13:55, Andrew Jeffery wrote:
> On Tue, 15 Feb 2022, at 13:42, Dhananjay Phadke wrote:
>> On 2/14/2022 3:13 PM, Patrick Williams wrote:
>>> On Mon, Feb 14, 2022 at 11:14:53AM -0800, Dhananjay Phadke wrote:
>>>> 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.
>
> This might separate the logic out in a way that's acceptable to Alex.
>
> Let me poke at it.
I've thought about this some more and adding support for
`required-mode = "none";` or similar seems like a massive footgun given
that (as I understand it) the FIT image as a whole isn't verified. Only
supporting "all" or "any" seems okay because some verification must
succeed in the context of the keys available in the current stage.
After some internal discussion this effort has been set aside so I'm not
going to pursue it further for the moment. I don't think it's easy to
proceed anyway without feedback from Alex.
Andrew
More information about the openbmc
mailing list