On 2/27/22 19:29, Andrew Jeffery wrote:
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.thir...@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.
Don't let my thoughts stop you. I don't think there is a perfect way to
address this situation, and we don't have to. Code can be changed later.
As a general preference, I would like to see a single decision point on
whether to verify/skip. It can be changing `required-mode = "none", or
any other similar solution. Keep in mind that the FIT is the image
you're trying to authenticate. It is completely different from
"required-mode", which is part of u-boot's or SPL's embedded dtb.
Alex
