Re: [coreboot] FSP 2.0 headers in coreboot

On Tue, May 22, 2018 at 2:25 PM, Youness Alaoui wrote: > On Fri, May 18, 2018 at 2:59 PM, Nico Huber wrote: >> >> I have to admit, I don't like your patch. While it gets the job done, >> it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the

Re: [coreboot] FSP 2.0 headers in coreboot

On Fri, May 18, 2018 at 2:59 PM, Nico Huber wrote: > > I have to admit, I don't like your patch. While it gets the job done, > it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the state in > coreboot as a whole would match neither version. > Good point. It is a

Re: [coreboot] FSP 2.0 headers in coreboot

On 18.05.2018 20:59, Nico Huber wrote: > Well, my vote, in order of preference: > > 1. Poke Intel. > 2. Get a verbatim copy of the GitHub headers in (in a way of effort for * least effort > the community). Maybe in a month from now? no matter the outcome > from 1. > > Nico > --

Re: [coreboot] FSP 2.0 headers in coreboot

On 11.05.2018 21:18, Youness Alaoui wrote: > I feel like this discussion is getting slightly out of hand, so let's > try to regroup a bit and move the discussion back to the original > topic : how to handle the FSP headers in coreboot. > I fully understand and agree with Nico's frustration about

Re: [coreboot] FSP 2.0 headers in coreboot

I feel like this discussion is getting slightly out of hand, so let's try to regroup a bit and move the discussion back to the original topic : how to handle the FSP headers in coreboot. I fully understand and agree with Nico's frustration about the blobs situation and I think that's a bigger

Re: [coreboot] FSP 2.0 headers in coreboot

On 11.05.2018 01:39, Timothy Pearson wrote: > Not to jump too far into the fray, but couldn't this be handled by > simply not blocking coreboot development on proprietary blobs? For > instance, if someone wants to implement a feature that requires > repository-wide changes (e.g. the timestamp

Re: [coreboot] FSP 2.0 headers in coreboot

On 11.05.2018 01:32, Aaron Durbin wrote: > On Thu, May 10, 2018 at 5:10 PM, Nico Huber wrote: >> Ok, I'll try to break this loop here. You are repeating the great bene- >> fits for a user (that I agree to) even if a blob is involved. And I keep >> asking why it should happen on our

Re: [coreboot] FSP 2.0 headers in coreboot

On 11.05.2018 01:31, Julius Werner wrote: >> Ok, I'll try to break this loop here. You are repeating the great bene- >> fits for a user (that I agree to) even if a blob is involved. And I keep >> asking why it should happen on our master branch (I don't see how we >> would take something away by

Re: [coreboot] FSP 2.0 headers in coreboot

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Not to jump too far into the fray, but couldn't this be handled by simply not blocking coreboot development on proprietary blobs? For instance, if someone wants to implement a feature that requires repository-wide changes (e.g. the timestamp stuff

Re: [coreboot] FSP 2.0 headers in coreboot

On Thu, May 10, 2018 at 5:10 PM, Nico Huber wrote: > Ok, I'll try to break this loop here. You are repeating the great bene- > fits for a user (that I agree to) even if a blob is involved. And I keep > asking why it should happen on our master branch (I don't see how we > would

Re: [coreboot] FSP 2.0 headers in coreboot

> Ok, I'll try to break this loop here. You are repeating the great bene- > fits for a user (that I agree to) even if a blob is involved. And I keep > asking why it should happen on our master branch (I don't see how we > would take something away by not maintaining everything. Also, I never >

Re: [coreboot] FSP 2.0 headers in coreboot

Ok, I'll try to break this loop here. You are repeating the great bene- fits for a user (that I agree to) even if a blob is involved. And I keep asking why it should happen on our master branch (I don't see how we would take something away by not maintaining everything. Also, I never tried to

Re: [coreboot] FSP 2.0 headers in coreboot

> You really seem to miss the point of free software. Okay, now this is starting to get personal again, let's please not go there. You too have been among those who spoke out against that in that derailment thread recently. It's insulting to insinuate that some of us don't understand or don't

Re: [coreboot] FSP 2.0 headers in coreboot

In general, I like Nico's idea of setting up rules for blobs, but my worry is that no matter how great and logical the rules are, the blob-makers might simply ignore them.. you can ask for signed blobs, but what if they refuse to sign it? Or even better, you can ask for redistributable blobs, but

Re: [coreboot] FSP 2.0 headers in coreboot

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

Re: [coreboot] FSP 2.0 headers in coreboot

> 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

Re: [coreboot] FSP 2.0 headers in coreboot

Sorry for being late to answer to my own thread (busy busy busy). A few notes : The initial check-in of the kabylake FSP was uploaded with a BSD license : https://github.com/IntelFsp/FSP/tree/d88078a708e768c7b6ee5cbc996299d303c3c702/KabylakeFspBinPkg Later commits added Intel's Restricted Use

Re: [coreboot] FSP 2.0 headers in coreboot

On 09.05.2018 01:04, Nico Huber wrote: > 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

Re: [coreboot] FSP 2.0 headers in coreboot

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

Re: [coreboot] FSP 2.0 headers in coreboot

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

Re: [coreboot] FSP 2.0 headers in coreboot

On 06.05.2018 00:03, Aaron Durbin wrote: > On Sat, May 5, 2018 at 5:36 AM, Nico Huber wrote: >> On 04.05.2018 23:41, Aaron Durbin via coreboot wrote: >>> On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui >>> wrote: Hi, I've just pushed

Re: [coreboot] FSP 2.0 headers in coreboot

On Sat, May 5, 2018 at 5:36 AM, Nico Huber wrote: > On 04.05.2018 23:41, Aaron Durbin via coreboot wrote: >> On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui >> wrote: >>> Hi, >>> >>> I've just pushed a commit for review on gerrit >>>

Re: [coreboot] FSP 2.0 headers in coreboot

On 04.05.2018 23:41, Aaron Durbin via coreboot wrote: > On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui > wrote: >> Hi, >> >> I've just pushed a commit for review on gerrit >> (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to >> open the

Re: [coreboot] FSP 2.0 headers in coreboot

On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui wrote: > Hi, > > I've just pushed a commit for review on gerrit > (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to > open the discussion here on whether the public coreboot code should > have the

[coreboot] FSP 2.0 headers in coreboot

Hi, I've just pushed a commit for review on gerrit (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to open the discussion here on whether the public coreboot code should have the FSP headers that match the public FSP headers or if they should match the 'google fsp' headers. My