Hi Kyösti,
you're asking for leadership opinion. Stefan (who you Cc'd) is on vacation right now.
Depending on how you define leadership, I might be part of it (in terms of the SFC, I'm part of an adviser group to leadership).
I can't claim to speak for anybody but myself here (although I'm aware that I'm using my corporate email address and have a certain standing in the coreboot community, so take that with as little or as much salt as you consider appropriate).
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.
So which of the following approaches do You find acceptable:
Generally speaking, from a license perspective, ...?
Note that vboot_reference is BSD-licensed, so depending on how this is implemented specifically, GPL compliance might not matter much.
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'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.
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).
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