On Tue, 15 Feb 2022, at 05:44, Dhananjay Phadke wrote:
> On 2/13/2022 5:13 PM, Andrew Jeffery wrote:
>> Right, I think this question is an indication that I could write a more
>> informative commit message, so if we converge on something acceptable
>> I'll update it. Let me provide some more context:
>>
>> As mentioned above this is motivated by use with BMCs, specifically on
>> the ASPEED AST2600, in some specific platform contexts.
>>
>> Platforms can be designed with two styles of firmware management in
>> mind:
>>
>> 1. The typical approach - No owner control: Manufacturer supplied
>> firmware with secure-boot always enabled
>>
>> 2. The atypical approach - Full owner control: Owner-controlled firmware
>> with secure-boot optionally enabled
>>
>> For quite a few contributing to OpenBMC, the manufacturer and the owner
>> are the same, and so the typical approach is a good match. It probably
>> is the use case Dhananjay was considering[1]. It also caters to the
>> traditionally closed-source firmware ecosystem where manufacturer
>> control is retained.
>>
>> [1]https://lore.kernel.org/openbmc/016ae207-2ecb-1817-d10e-12819c8c4...@linux.microsoft.com/
>>
>> The second approach requires open-source firmware stacks combined with
>> platforms designed to enable owner control. There are some ecosystems
>> that allow this (e.g. OpenPOWER). On the host side for those systems
>> it's possible to secure-boot them using firmware and kernels signed
>> entirely and only by user-controlled keys. We're looking to enable this
>> for the BMC side too, as much as we can.
>>
>> For completeness (i.e. stating this to make the argument self-contained,
>> not implying that you're unaware of it), for secure-boot to be
>> meaningful at a given point in the boot process we need all previous
>> elements of the boot process to have been verified. That is, it's not
>> enough to verify u-boot if the u-boot SPL is not verified.
>>
>> Where such systems use the AST2600, limitations of the AST2600
>> secure-boot design come into play:
>>
>> 3. All secure-boot configuration is held in OTP memory integrated into
>> the SoC
>>
>> 4. The OTP memory must be write-protected to prevent attackers
>> installing arbitrary keys without physical presence
>>
>> 5. The OTP is write-protected by configuration held in the OTP.
>>
>> The consequence with respect to 2. is that the system manufacturer
>> either must:
>>
>> 6. Program and write-protect the OTP during production, or
>>
>> 7. Ship the system with the OTP in a vulnerable state.
>>
>> We figure the latter isn't desirable which means dealing with
>> limitations of the former.
>>
>> If the OTP is programmed (with the required public keys) and
>> write-protected by the manufacturer, then when configured as a
>> secure-boot root-of-trust, the AST2600 must only boot an SPL image
>> signed by the manufacturer. From here there are two options for owner
>> control:
>>
>> 8. The manufacturer signs arbitrary SPLs upon request. This requires
>> trust from both parties and potentially a lot of auditing focus from the
>> manufacturer.
>>
>> 9. The manufacturer publishes the source for the signed u-boot SPL
>> binary in a fashion that allows reproducible builds for verification by
>> inspection. Firmware signed by owner-controlled keys can only be applied
>> beyond this boot stage.
>>
>> Despite the compromise, the latter approach seems to be the most
>> reasonable in the circumstances.
>>
>> Again for completeness, broadly, security can be divided into two
>> categories:
>>
>> 10. Software security
>> 11. Physical security
>>
>> Controlling secure-boot in a way that requires physical presence rules
>> out the ability to influence the boot process via (remote) software
>> attacks. This is beneficial. The approach at the platform level does not
>> yet solve for physical security, however given this is motivated by use
>> on BMCs, physical security concerns could be viewed as taken care of in
>> the sense that the systems are likely installed in a datacenter or some
>> other controlled environment.
>
> 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.
Right. They are decoupled. What I'm proposing in the patch only affects
FIT verification.
Cheers,
Andrew
