[coreboot] FSP 2.0 headers in coreboot

[Nico Huber]

On 10.05.2018 00:17, Julius Werner wrote:
>> Yes, I agree and already did so when writing the above. That's why I
>> made it a recommendation and not a requirement. I also intentionally
>> didn't write "vendor". Just whoever provides the blob should sign it.
> 
> I still don't really get what signing in general is solving here. Digital
> signatures are only useful if you want the signer to be able to make a new
> release without having to update the thing that's checking the signature.

No, it's about convenience, trust, security. Even if you only sign once.
If you can get the public key for verification out-of-band, an attacker
would have to compromise both, the repository and the key distribution.
The signee has nothing more to do than sign it, keep the signature along
with the binary. That's easier than comparing hashes.

> Otherwise you can just store a list of allowed hashes, which is much easier

That's another way for an out-of-band trust anchor. IMHO more incon-
venient but ok if you keep that list far away from the repository.

> (and already implicit in Git if you use the coreboot.org blobs repository).

Sounds just more error-prone and inconvenient to me. Sure you can follow
hashes in Git, but if you cherry-pick somewhere, you can't. With our
process with Gerrit for instance, you'd have to verify that the file
that ended up upstream is still the same (doable, sure, but checking
another time? I'm getting bored). And where do you store the information
that you actually did check? If somebody asks you two years later if
you did, what would you say?

> In the Intel case maybe signing them makes sense, but it shouldn't be a big
> deal to just maintain a list of FSP releases with their hashes in the
> coreboot repo either... at least that way you maintain control over which
> blobs are valid

Who is `you` in "you maintain control"? It's one thing to trust a single
person who provided the blob (hopefully the silicon vendor if you need
it for a product). But a very different thing to trust everybody who can
write to our repository. Or should somebody who checks the hash also
check the history of the list? check who changed it? (or who was imper-
sonated to change it) Blobs aren't reviewable, are they?

> (e.g. you could enforce that they have been tested with
> coreboot before inclusion).

How? You can make it a rule, yes. But how enforce it?

> If you just let Intel sign stuff, you're giving
> them complete control over this thing that I think you intend as a
> protection for our users. They could sign a special blob for the NSA and
> you'd never know until you accidentally catch it running on someone's
> system.

I don't understand your reasoning here. Ofc, the blob vendor can screw
you. But that's the point of blobs, isn't it?

> (Or do I misunderstand and you're talking about signatures checked
> at runtime? That wouldn't really make sense on a per blob basis when the
> rest of coreboot isn't signed, I think. If you want runtime signatures,
> it's better to use a system like vboot that covers the whole image,
> coreboot and blobs and all.)

No, you understood me correctly. I just want a trustworthy distribution
of the binaries.

To wrap it a little up, I really only had the bigger players in mind
when I wrote my draft rules. And I understand your point for a one time
blob submission (why set a key pair up for that). You get equivalent
security with a hash that is distributed out-of-band. So that option
should be added if we ever agree on such rules.

Still, if somebody pushes a platform for inclusion on the master branch,
and thereby asking to maintain it, I don't see why he shouldn't take the
time to sign the blob (ofc, if he runs off later, somebody else (i.e.
who already verified the original signature) could take that responsi-
bility over).

> 
>>> Of course it would be nice if every chipset was implemented well enough
>>> that you can bring up a new mainboard without any help from the vendor, but
>>> that's not always that simple, and I don't think it should be a requirement
>>> for inclusion.
> 
>> Sorry, I thought that is what free software is about. Must have been
>> confused to mix that up with coreboot. IMO, blobs are already a huge
>> offense, a disgrace of coreboot and the GPL. But having to sign an NDA
>> to be able to use a GPL licensed project in a product? WTF?!?
> 
>> I don't care if people think that their loopholes are safe enough and
>> use coreboot that way. But why should the community, including many
>> volunteers, maintain that junk on the master branch?
> 
>> If that is the attitude moving forward, maybe we should stop licensing
>> new code under the GPL? Just as a courtesy towards free-software develo-
>> pers. And to make it clear for new contributors what they sign up for.
> 
> I think you're getting pretty absurd for the sake of argument here. A
> different mainboard is a completely different device, of course it may not
> run with the firmware meant for another device. Complaining about this as a
> GPL violation is like saying that Intel was violating the GPL by adding a
> Haswell port to coreboot and then not allowing you to support a Skylake
> board with that.

No idea what you are trying to tell here? I didn't talk about (strong
feelings about) violations. But let me clarify my point of view:
Everybody with the time and resources to put things into a blob seems
to be excluded from the copyleft nature of the GPL (so we don't get
much contribution from the big players). Yet, OTOH, we force the more
humble that don't have the big resources to adhere to the copyleft. If
we accept that, the GPL has failed us and we shouldn't keep it, IMHO.

> It's a completely different thing, of course the code
> meant for something else doesn't work on there.

Yeah, but once this was a free-software project. Which implies that you
can adapt the code to something new. Which you can't with a blob.

> 
> Of course I think we should try to keep blobs mainboard-agnostic, and
> whenever I have a chance to influence that I do. But it's not always that
> simple. Often you may not realize that it won't work on another board until
> you actually build that board and try it out. It's not like anyone is
> actively preventing or disallowing you from bringing up another mainboard
> with the same blob that's already there, and if your other board uses 100%
> the same components as the original then that should always work... but if
> you find out you need to use some controller or I/O pad that this blob
> didn't initialize because other mainboards didn't need it, then yeah,
> sorry, it won't work. It's not like anyone did that intentionally, it's
> just bad luck. I think this is conceptually the same as when you have a
> completely blob-free platform but you want to use some peripheral that
> nobody ever implemented a driver for before. You'll need help from the
> vendor then as well.

You really seem to miss the point of free software. As long as everybody
adheres to the copyleft, you can do things on your own. If a blob ends
up being only useful for a single board, ok. Should somebody be able to
sell his product with it, sure. But why should the community maintain
that shit (partially on the shoulders of volunteers) if it doesn't pro-
vide what free software provides?

Nico