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