Hello Aaron, thanks for your reply.
On 30.04.2018 05:22, Aaron Durbin wrote: > On Sat, Apr 28, 2018 at 7:16 AM, Nico Huber <[email protected]> wrote: >> Hello coreboot folks, hello Intel and Google coreboot developers, >> >> back on Tuesday, some of us discovered a commit on gerrit [1] that >> implements (another) foreign interface inside coreboot. Discussing > > It's more of a bridge into coreboot's infrastructure, imo. It is. Anyway, maybe discuss that in another thread or on gerrit. > >> it didn't go well and I kind of bursted. I feel sorry about that now >> (especially because I got too personal). >> >> One of the causes for this clash definitely was that things apparently >> were discussed before but not with coreboot (i.e. this coreboot mailing >> list). So I'll try to take the general discussion here, but I've to >> start some years back, where you lost me. >> >> Some questions (that I believe have to be answered) right away. I'll >> argue about why later, so these won't get lost (in an already too long >> email): >> >> >> TLDR; >> For Google: >> You kind of introduced blobs in coreboot (with Sandy Bridge) which was >> a simple jump-in-jump-out thing and kind of accepted. The argument was >> that the things it does aren't documented by Intel anymore, AFAIR. But >> with Broadwell suddenly another blob emerged (in ramstage) some >> `refcode.elf` AIUI. It turned out, later, that this blob (also) does >> things that were open source for Haswell (and would work verbatim on >> Broadwell). It seems to play a role comparable to FSP-S. >> o What's the story behind this blob? >> o Why was it introduced? >> o Was there more than IP concerns? Time to market pressure maybe? > > Saying it's comparable to FSP-S is apt. The story is, like most > things, that it has specific things that are not architectural that > Intel thinks they need to be secret. Typical settings are related to > power management. When needing to be competitive in the laptop space > power is a big concern. Time to market may have been a thing too, but > I don't recall all the specifics. I'll get to it later in the > response, but there are temporal components to decisions and/or how > things change over time that are not within Google's control when > working on a particular platform. > >> >> For Intel: >> It's hard for me to understand what parts of your silicon init you can >> open-source and what parts you can't. I know your BIOS Writer's Guides >> (BWG) / BIOS Spec, and many things therein are often published by you >> or Google. Please tell us. >> o Are the things that you can *not* open-source documented at all? >> o if so, in these BWG documents? >> o Or is everything in these documents generally publishable (with >> some NDA clearance, ofc)? >> o For a configuration of FSP-S that just runs the bare minimum to >> boot (e.g. skips questionable add-ons like TXT, SGX), is there >> anything not publishable? >> o Can anything be done to get more documentation published? e.g. >> for things that are done in open source (or were done in the past) >> but are not publicly documented. > > Based on my working history a lot of BWGs and/or specs are usually > wrong. They don't always contain the right information, but generally > contain quite a few things that are wrong where you second guess > everything in the docs. This should sound familiar: the 'reference > code' is the documentation. Most docs are not in sync with reality or > necessarily with how the silicon was actually designed. It's my belief > when there wasn't as much change from version to version, the > copy-pasting in docs just kinda worked. But as things have been > getting more complicated and incorporating more 'features' the > documentation has not been keeping up. Still these documents exist. And I deem them most valuable. I know there are flaws that can drive you crazy. But! they give a very good overview about what has to happen for silicon init. If published (for my sake w/o the secret ingredient bits) [2], they would be a great reference for discussions about the design of clean silicon-init code. We could har- ness the power of the community much better. It doesn't matter if somebody with access to the reference code has to fix some bugs later, once you have a decent maintainable code base. Neither would a blob that hides the secret ingredients if it only con- tains those (and no infrastructure / control flow; I think you, Aaron, and me share the same opinion on that). > >> >> >> So why ask? The original introduction of blobs in coreboot in general >> happened with the argument that the things it does (e.g. memory init) >> are not documented anymore by Intel. This is a valid argument because >> the lack of documentation makes it harder to write clean code. I also >> believe it's true (that no documentation exists) because I've seen a >> previous BWG that already referred a lot to the reference code. >> >> But, AFAIR, the introduction of blobs in coreboot's *ramstage* was never >> discussed. The blobs I've seen so far all did things that were already >> open source for earlier platforms. Plus they are twisting coreboot into >> something that isn't coreboot anymore. Architectural changes happen in >> chipset specific code instead of moving coreboot as a whole (after an >> open discussion). Also, most of the positive aspects about coreboot are >> lost. > > Purely business commentary: In order to develop a competitive laptop > on recent hardware one needs to include the features that consumers > expect. Intel also ties those features inside of FSP, but FSP has a > responsibility problem. It has traditionally attempted to do things it > should not. FSP should be a library of sorts, but it has things in > there it shouldn't. I mentioned some of this on the CL itself about > our usage of SkipMpInit. It trying to take over resources that it > shouldn't (among other things). > > What architectural changes are you referring to? And what is your You've got me there. I meant architectural things, not changes. Like that patch on gerrit. It doesn't seem to be Intel specific, I also can't find any soc_ reference in it. Yet, it's pushed to soc/intel/ and to me that looks like somebody wants to sneak it it (without big discussion / being thought through for all of coreboot). > definition of coreboot (I know see you wrote it below :)? early > firmware that will initialize everything in open source for Intel > platforms? I wish that were the case, but it's not something that is > allowed by Intel currently. I'd love to see more granularity in FSP, > but as noted in the CL commentary Intel hasn't been accepting of my > suggestions for making things more granular such that one could do the > only things that are deemed 'super secret' by Intel. The muddling of > responsibility and lack of granularity are the current result. > >> >> Of course, it's hard to argument about whether something is coreboot >> or not without a clear definition of coreboot. But let me get this >> one straight: It's definitely not coreboot just because it happens on >> coreboot.org. >> >> I'll try to sum up what is coreboot to me, and compare that to a current >> coreboot with FSP. coreboot >> >> 1. is free software >> 2. is open source >> 3. is auditable >> 4. is lean (less code means less bugs) >> 5. gives control to the user >> >> but with FSP: >> >> 1. You can not fully adapt it, you can't even just download it (often >> have to steal the FSP binary): >> 0% >> 2. Comparing the sizes of open-source parts and FSP, maybe 30%. But >> if you don't count open-source code that is only needed to handle >> blob issues, rather >> 20% > > Is this 20-30% coreboot/open source of the total? Were you counting > the edk2 stuff in there? A lot of the bloat in FSP comes from open > source edk2. You can't count EDK2 into it. Once it's built into FSP, it's not open- source any more (unless somebody proves what parts match a reproducible compilation of the open-source code). And for an open-source experience you'd still need means to adapt these EDK2 parts in the binary. It was just a wild guess based on my experience with Kaby Lake FSP (~500KiB), and guessed 200KiB coreboot. > >> 3. If you are backed by a huge company or government, you can audit >> coreboot+FSP (I guess), if not than not, 50%? But given that the >> size of the whole package is about 10 times the size of a clean >> implementation, you have to audit 10 times more code (of much >> poorer quality), thus at most >> 5% >> 4. 0% (see above) >> 5. That seems to be my only point that Intel cares about. Still, >> coreboot compatible binaries are often not available. You need >> very weird workarounds if the one setting you miss is not there: >> 50% >> >> Numbers are just educated guesses, but might match reality. If you >> average these, you'll see that coreboot+FSP is only 15% of (my) >> coreboot. I would estimate that you can get up to 20% with the >> design of FPS2.0. > > I agree with the overall assessment above. As currently > deployed/supported FSP is not really geared to people who don't have a > more intimate relationship with Intel. It's been brought up numerous > times, but it's Intel's decision to make a better product. Right, quality of their products is up to them. But isn't it our re- sponsibility to decide whether they can do that (15%) in the name of coreboot? Nico [2] Assuming that the BWGs don't contain the secret ingredients, even an NDA offer to all coreboot developer's (both hired ones and indi- viduals) could help. If Intel allows to derive open-source code from it (e.g. after a private review on gerrit) people would have less doubts about signing an NDA, IMHO. Just a random thought; anything I can come up with atm seems to be better than the status quo. >> >> So it's time for an FSP3.0 that was designed with the community, >> I'd say. >> >> Best regards, >> Nico >> >> [1] https://review.coreboot.org/#/c/coreboot/+/25634/ -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
