[coreboot] FSP 2.0 headers in coreboot

[Nico Huber]

On 08.05.2018 20:35, Julius Werner wrote:
>>>>      Providers of blobs should sign them and take responsibility
>>>>      that the signed blobs were unaltered after compilation (e.g.
>>>>      do not contain malware). It is *recommended* that the public
>>>>      key needed to verify the signature is obtainable through a
>>>>      specific channel (e.g. single responsible contact person)
>>>>      _independently_ from the blob's distribution path.
> 
> I'm not quite sure what the point of this would be for blobs that are
> already checked into 3rdparty/blobs, and I could imagine that it would be a
> surprisingly big obstacle for a lot of vendors. Please don't only think of
> Intel when trying to make these rules... not every vendor has the resources
> to set up their own blob distribution site with regular versioned releases
> on GitHub. On Arm systems the blob may often be designed specifically for
> coreboot, and the vendor loses interest as soon as the project they were
> paid to support (e.g. a Chromebook) is finished. I think this should still
> be fine as long as they uploaded it with a proper redistribution license to
> blobs.git, and implemented the coreboot interface with enough documentation
> to make it usable afterwards. For vendors like Intel that insist on hosting
> their blobs externally, I think it's fair to impose more rules to avoid the
> problems you've described, but we should still leave open an easier option
> for vendors that are willing to redistribute their blobs through
> coreboot.org (which I think is the much nicer option for us, so we should
> incentivize it).

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.

> 
>>>>      For each platform that relies on a blob, the coreboot tree
>>>>      *should* point (e.g. git submodule) to a commit containing
>>>>      both the header files and the matching binary.
> 
> It seems like you want to move headers from the coreboot into the blobs
> directory? I don't really see the point in that either. Headers are source,
> they need to be covered under the GPL... it's easier to make that clear
> when they are in coreboot. I agree with your point that headers and blobs
> should always be updated together, but we can still enforce that across two
> repositories.

Ack. It's technically the same if you change a pointer to both or change
the pointer to the binary together with the header files in one commit.
But it's easier to make mistakes in the latter case. (I might be too
biased here as I've seen too much chaos with these things.)

> 
>>>>      Unless a pointer as described above exists for a given plat-
>>>>      form that relies on a blob, all changes* to that platform
>>>>      *shall* be refused.
> 
> I think this is counter-productive, as is removing any old boards that
> don't comply. I am okay with creating new rules for future platforms, but
> there is no reason to throw perfectly good and working boards out just
> because they weren't written to comply with something we only just made up.
> You wouldn't really be punishing anyone with that (vendors don't care about
> outdated chips anyway), you'd just be taking choice away from our users.

Well, that's why I brought older Intel based CrOS devices up. I think
they are the only ones that currently can't comply. I agree that we
should have an exception for older platforms. But it's not really
something "just made up", IMHO. Google made their own rules when
bringing blobs in with Sandy Bridge, just to break them later. So the
problem was obviously already visible when these platforms were added.

> 
> We should continue removing old boards when they become too much of a
> maintenance burden, which may happen due to an unmaintainable blob mess,
> but we shouldn't categorically remove anything with blobs.
> 
>> OTOH, what's the benefit of maintaining them in the master branch if
>> nobody else can do a port with the platform code?
> 
> I think allowing users to build their own custom firmware for an already
> supported board is definitely reason enough to keep it in the master
> branch. coreboot is not just a project for allowing companies large and
> small to build new mainboards... it's also for private enthusiasts that
> want to tinker with firmware for a supported board they bought somewhere.

While I don't see why that has to happen on the master branch, you have
a point there. Let's just say all the `shall`s only apply to binaries
released from 4.8 on.

> 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.

Nico