On Fri, Aug 23, 2019 at 3:06 PM Patrick Georgi <pgeorgi(a)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
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
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
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
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.
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
for us. Doesn't mean that they're the only way to approach
things. (Example: Intel recommending to use FSP-T instead of open
b) Platform shall use vboot, built and signed
internally at AMD, for
the Security Processor (aka PSP), using their choice of proprietary
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
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
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
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
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
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.
Thanks for you time and opinions,