Open letter to coreboot leadership
I have spent some time helping out sort some fundamentals on the tree to bring up that new amd/picasso platforms. During the reviews I found some proceedings there somewhat alarming, so I am hoping for coreboot leadership and trademark holder to make some clear statements on the topic.
Now, I may know a bit more than I can write here in public, I try defer from disclosing information received in private emails and stick with the information that can be found in gerrit review commits. In short; appers it has been decided verstage will run on PSP instead of x86 cores.
So which of the following approaches do You find acceptable:
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.
b) Platform shall use vboot, built and signed internally at AMD, for the Security Processor (aka PSP), using their choice of proprietary tools. 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.
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.
f) Something else in between the presented choices or outside of them?
Regards, Kyösti Mälkki
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
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
On Fri, Aug 23, 2019 at 05:11:39PM +0300, Kyösti Mälkki wrote:
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.
coreboot itself is still open source. FSP is a mixed bag in that it enabled going on with contemporary hardware but also seemed to have killed all motivation to reverse engineer chipset bringup - or maybe that's due to the omnipresent ME on the same devices that made CPU-side reverse engineering seem useless because the ME firmware is still there?
As for "maximum control", it's still a local maximum you can achieve on that type of devices (unless people start reverse engineering, or silicon vendors stop being to stuck up on keeping "write magic value to magic register" code secret, in which case we could raise the bar).
I wish we could reach the global maximum as well, but that's not in our hands.
And here we end up with the age old disagreement in whether we should be open to compromise and keep the conversation going (hopefully in the right direction, although sometimes that's hard) or take our toys and leave.
Patrick
On Fri, Aug 23, 2019 at 9:25 PM Patrick Georgi pgeorgi@google.com wrote:
I wish we could reach the global maximum as well, but that's not in our hands.
And here we end up with the age old disagreement in whether we should be open to compromise and keep the conversation going (hopefully in the right direction, although sometimes that's hard) or take our toys and leave.
Well, not quite the age old disagreement, but close.
In the case of AMD Picasso I believe those conversations about the role of PSP have been completed, behind closed doors, sometime last spring. Is everything still under non-disclosure about those made compromises, or is someone willing to reveal in public what we should expect this time?
Kyösti
On Fri, Aug 23, 2019 at 10:23:06PM +0300, Kyösti Mälkki wrote:
Is everything still under non-disclosure about those made compromises, or is someone willing to reveal in public what we should expect this time?
I don't know timelines, decisions made or agreements under which these were made (e.g. NDAs).
I'll point out the thread to people who may know more, but I can't promise a response given that I don't know the constraints.
Patrick
On Fri, Aug 23, 2019 at 10:32 PM Patrick Georgi pgeorgi@google.com wrote:
On Fri, Aug 23, 2019 at 10:23:06PM +0300, Kyösti Mälkki wrote:
Is everything still under non-disclosure about those made compromises, or is someone willing to reveal in public what we should expect this time?
I don't know timelines, decisions made or agreements under which these were made (e.g. NDAs).
I'll point out the thread to people who may know more, but I can't promise a response given that I don't know the constraints.
Sometimes it is not that I didn't know who to ask, but that I receive partial answers in private email exchange. Since they know I am not under their NDA, any information they give me in private emails should equally be available to other developers. And yes, it's not really my problem if they are breaching or bending their NDA, it's theirs. I read several paragraphs about this vboot/verstage running on PSP and all that should have just appeared under Documentation/ instead.
Regarding this thread; at least the question about toolchain remains without an answer. If we go back to early amd/stoneyridge, the first iteration wanted to call (unverified but possibly read-only) AGESA blob from within bootblock, before verstage. I believe the approach was vetoed and rejected by some security advisory team at Chromium, invalidating perhaps a couple month's worth of development work? We are dealing with verstage here again, I want confirmations that the compromises get evaluated before we put more effort on attempts to merge the work.
Kind Regards, Kyösti Mälkki
----- Original Message -----
From: "coreboot" coreboot@coreboot.org To: "Kyösti Mälkki" kyosti.malkki@gmail.com Cc: "coreboot" coreboot@coreboot.org, "Stefan Reinauer" reinauer@google.com Sent: Friday, August 23, 2019 1:25:23 PM Subject: [coreboot] Re: Verified boot on AMD Picasso
coreboot itself is still open source. FSP is a mixed bag in that it enabled going on with contemporary hardware but also seemed to have killed all motivation to reverse engineer chipset bringup - or maybe that's due to the omnipresent ME on the same devices that made CPU-side reverse engineering seem useless because the ME firmware is still there?
Speaking for myself, the latter applies. I had the knowledge and willingness to keep working on newer native AMD init some years back, *except* that with the PSP forced on those platforms I saw no purpose in doing so. Instead I went back and focused on platforms that could be fully owner controlled, and partly as a result the native AMD init even for the old PSP-free 15h platforms is now rotting and dying out.
I started a new thread to discuss updates the Web site. Irregardless of developer opinion, I have seen firsthand user confusion over the statements on the site; this means the statements do need clarification. I have proposed some updated text in the other thread.
There is still room for both proper native init and the "glue" frameworks, just on completely different platforms. Let's not kill one off entirely to force the other, but at the same time we do need to be very clear in words that non-technical people may understand just what is what.
Thanks!
-- Timothy Pearson Raptor Engineering, LLC https://www.raptorengineering.com
-
Kyösti Mälkki -
Patrick Georgi -
Timothy Pearson