On Fri, Aug 23, 2019 at 3:06 PM Patrick Georgi pgeorgi@google.com wrote:
On Fri, Aug 23, 2019 at 02:38:13PM +0300, Kyösti Mälkki wrote:
short; appers it has been decided verstage will run on PSP instead of x86 cores.
verstage isn't used for all coreboot configuration, and while it originated with Chrome OS firmware it has been extended to cover other use-cases as well. It might help if you could outline the impact to various scenarios.
At the moment I don't know if verstage will be compulsory on amd/picasso. While the commercial development may target Chromebooks only, it would be nice to leave the opportunity for community ports using same SoC. Admittedly, that community interest never surfaced with amd/stoneyrige or any of the other older binaryPI platforms.
So which of the following approaches do You find acceptable:
Generally speaking, from a license perspective, ...?
Quoting website frontpage; "As an Open Source project it (coreboot) provides auditability and maximum control over technology. "
FOSS to blob ratio in coreboot images, when only accounting for x86 code, is something like 1:8 with recent Intel hardware and FSP. I am wondering if trademark holder wishes or dares to draw the line somewhere.
Note that vboot_reference is BSD-licensed, so depending on how this is implemented specifically, GPL compliance might not matter much.
Right, GPL may not apply. Just that for x86 vboot links with coreboot console code, that's where the reference for GPL compliance came from.
That said:
a) Platform shall use proprietary ARM TrustZone instead of vboot for any cryptographics and measurements of firmware. This may be the AMD endorsed way of doing things.
Silicon vendors often endorse things that seem nonsensical for us. Doesn't mean that they're the only way to approach things. (Example: Intel recommending to use FSP-T instead of open CAR code).
b) Platform shall use vboot, built and signed internally at AMD, for the Security Processor (aka PSP), using their choice of proprietary tools.
Non-opensource toolchains are often much more painful to deal with than the opensource ones. If they want to inflict that pain onto themselves, there's little we can do about it.
While GPL compliance may say build scripts are to be published in such case (IANAL!!), that does not mean the used compiler is available for purchase on open market.
As discussed above: that depends a lot on what the actual implementation looks like.
c) Platform shall use vboot, built using an extended __and published__ coreboot toolchain. Built PSP vboot binary shall be reproducible and signed with OEM key. Community developers will not be able to run custom verstage builds, but are able to audit integrity of the source.
d) Platform shall use vboot, built using an extended __and published__ coreboot toolchain. Built PSP vboot binary should be reproducible. Community developers are able to run custom verstage builds, but state of PSP/TPM/etc may reveal to the OS that sections of the firmware does not originate from the OEM, as detected by the lack of signage or use of insecure key published for experimental use only. User experience or DRM might suffer.
e) Platform shall use vboot, built using an extended __and published__ coreboot toolchain. Developers can run whatever they want on PSP, without OS ever noticing it.
A generalization of d) would be preferable: Provide a secure channel to determine the signer of the firmware, no matter who that is. Some optional features (like DRM) could depend on having some form of "blessed" signature.
That way every customer and user could implement their desired security model without being able to impersonate anybody else.
I agree. I really wish options a) and b) would be ruled out for one reason or another.
I'm not sure about the thrust of your inquiry: Some of it sounds like damage control with regard to licensing (e.g. option b), options c to f sound more like collecting requirements for a platform's security model.
Major thrust is if verstage becomes yet another blob we cannot audit. In practice that happens in options a) and b). Having reproducible binary created with known reference toolchain is in my opinion the absolute minimal requirement.
Also with c) d) and e), it would be feasible to build rmodule loader into the PSP firmware and load romstage as an rmodule? (I am probably late with this idea, I believe tools have already been prepared to provide a compressed flat romstage binary instead, linked to a fixed DRAM location).
For the latter, we might be about 5 years late (unless AMD is still revising their boot ROM or PSP binaries, in which case anything might happen).
Well... AMD did roll out custom PSP for amd/stoneyridge Chromebooks some three years after silicon first hit the market?
That said, if we could get them to commit to a security model that enables security models for everybody (incl. Hollywood, centrally managed enterprise deployments and individual hackers), even for future hardware, that would be a significant success.
Regards, Patrick
Thanks for you time and opinions, Kyösti