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.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.
Regards,
Dhananjay
