[coreboot] FSP 2.0 headers in coreboot

[Julius Werner]

> 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.
Otherwise you can just store a list of allowed hashes, which is much easier
(and already implicit in Git if you use the coreboot.org blobs repository).
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 (e.g. you could enforce that they have been tested with
coreboot before inclusion). 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. (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.)

> > 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. It's a completely different thing, of course the code
meant for something else doesn't work on there.

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.