<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Arial,Helvetica,sans-serif;" dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Arial, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<div class="__TEE_Quote__" style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102); font-size: 17px;">
You are just, with this desperate chit-chat, fueling INTEL's big EGO.<br>
Please, continue to do so! INTEL, at the end of the day, will thank<br>
you for that! :-))</div>
<br>
Please keep things civil. Whatever you think of Intel and FSP, this is a good opportunity to improve support for coreboot and others reading this thread would like to see progress.
<p></p>
</div>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Arial, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> coreboot <coreboot-bounces@coreboot.org> on behalf of Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com><br>
<b>Sent:</b> Monday, April 30, 2018 9:58:33 AM<br>
<b>To:</b> Nico Huber<br>
<b>Cc:</b> Nathaniel L Desimone; Furquan Shaikh; Vincent Palatin; coreboot@coreboot.org; Aaron Durbin; Stefan Reinauer; Martin Roth; ron minnich; Shelley Chen; Julius Werner; Vadim Bendebury; Nick Vaccaro; Chris Ching; Duncan Laurie; Subrata Banik<br>
<b>Subject:</b> Re: [coreboot] Why do we have FSP-S</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Nico, Aaron,<br>
<br>
You are just, with this desperate chit-chat, fueling INTEL's big EGO.<br>
Please, continue to do so! INTEL, at the end of the day, will thank<br>
you for that! :-))<br>
<br>
Zoran<br>
_______<br>
<br>
On Mon, Apr 30, 2018 at 4:48 PM, Nico Huber <nico.h@gmx.de> wrote:<br>
> Hello Aaron,<br>
><br>
> thanks for your reply.<br>
><br>
> On 30.04.2018 05:22, Aaron Durbin wrote:<br>
>> On Sat, Apr 28, 2018 at 7:16 AM, Nico Huber <nico.h@gmx.de> wrote:<br>
>>> Hello coreboot folks, hello Intel and Google coreboot developers,<br>
>>><br>
>>> back on Tuesday, some of us discovered a commit on gerrit [1] that<br>
>>> implements (another) foreign interface inside coreboot. Discussing<br>
>><br>
>> It's more of a bridge into coreboot's infrastructure, imo.<br>
><br>
> It is. Anyway, maybe discuss that in another thread or on gerrit.<br>
><br>
>><br>
>>> it didn't go well and I kind of bursted. I feel sorry about that now<br>
>>> (especially because I got too personal).<br>
>>><br>
>>> One of the causes for this clash definitely was that things apparently<br>
>>> were discussed before but not with coreboot (i.e. this coreboot mailing<br>
>>> list). So I'll try to take the general discussion here, but I've to<br>
>>> start some years back, where you lost me.<br>
>>><br>
>>> Some questions (that I believe have to be answered) right away. I'll<br>
>>> argue about why later, so these won't get lost (in an already too long<br>
>>> email):<br>
>>><br>
>>><br>
>>> TLDR;<br>
>>> For Google:<br>
>>> You kind of introduced blobs in coreboot (with Sandy Bridge) which was<br>
>>> a simple jump-in-jump-out thing and kind of accepted. The argument was<br>
>>> that the things it does aren't documented by Intel anymore, AFAIR. But<br>
>>> with Broadwell suddenly another blob emerged (in ramstage) some<br>
>>> `refcode.elf` AIUI. It turned out, later, that this blob (also) does<br>
>>> things that were open source for Haswell (and would work verbatim on<br>
>>> Broadwell). It seems to play a role comparable to FSP-S.<br>
>>> o What's the story behind this blob?<br>
>>> o Why was it introduced?<br>
>>> o Was there more than IP concerns? Time to market pressure maybe?<br>
>><br>
>> Saying it's comparable to FSP-S is apt. The story is, like most<br>
>> things, that it has specific things that are not architectural that<br>
>> Intel thinks they need to be secret. Typical settings are related to<br>
>> power management. When needing to be competitive in the laptop space<br>
>> power is a big concern. Time to market may have been a thing too, but<br>
>> I don't recall all the specifics. I'll get to it later in the<br>
>> response, but there are temporal components to decisions and/or how<br>
>> things change over time that are not within Google's control when<br>
>> working on a particular platform.<br>
>><br>
>>><br>
>>> For Intel:<br>
>>> It's hard for me to understand what parts of your silicon init you can<br>
>>> open-source and what parts you can't. I know your BIOS Writer's Guides<br>
>>> (BWG) / BIOS Spec, and many things therein are often published by you<br>
>>> or Google. Please tell us.<br>
>>> o Are the things that you can *not* open-source documented at all?<br>
>>> o if so, in these BWG documents?<br>
>>> o Or is everything in these documents generally publishable (with<br>
>>> some NDA clearance, ofc)?<br>
>>> o For a configuration of FSP-S that just runs the bare minimum to<br>
>>> boot (e.g. skips questionable add-ons like TXT, SGX), is there<br>
>>> anything not publishable?<br>
>>> o Can anything be done to get more documentation published? e.g.<br>
>>> for things that are done in open source (or were done in the past)<br>
>>> but are not publicly documented.<br>
>><br>
>> Based on my working history a lot of BWGs and/or specs are usually<br>
>> wrong. They don't always contain the right information, but generally<br>
>> contain quite a few things that are wrong where you second guess<br>
>> everything in the docs. This should sound familiar: the 'reference<br>
>> code' is the documentation. Most docs are not in sync with reality or<br>
>> necessarily with how the silicon was actually designed. It's my belief<br>
>> when there wasn't as much change from version to version, the<br>
>> copy-pasting in docs just kinda worked. But as things have been<br>
>> getting more complicated and incorporating more 'features' the<br>
>> documentation has not been keeping up.<br>
><br>
> Still these documents exist. And I deem them most valuable. I know there<br>
> are flaws that can drive you crazy. But! they give a very good overview<br>
> about what has to happen for silicon init. If published (for my sake w/o<br>
> the secret ingredient bits) [2], they would be a great reference for<br>
> discussions about the design of clean silicon-init code. We could har-<br>
> ness the power of the community much better.<br>
><br>
> It doesn't matter if somebody with access to the reference code has to<br>
> fix some bugs later, once you have a decent maintainable code base.<br>
> Neither would a blob that hides the secret ingredients if it only con-<br>
> tains those (and no infrastructure / control flow; I think you, Aaron,<br>
> and me share the same opinion on that).<br>
><br>
>><br>
>>><br>
>>><br>
>>> So why ask? The original introduction of blobs in coreboot in general<br>
>>> happened with the argument that the things it does (e.g. memory init)<br>
>>> are not documented anymore by Intel. This is a valid argument because<br>
>>> the lack of documentation makes it harder to write clean code. I also<br>
>>> believe it's true (that no documentation exists) because I've seen a<br>
>>> previous BWG that already referred a lot to the reference code.<br>
>>><br>
>>> But, AFAIR, the introduction of blobs in coreboot's *ramstage* was never<br>
>>> discussed. The blobs I've seen so far all did things that were already<br>
>>> open source for earlier platforms. Plus they are twisting coreboot into<br>
>>> something that isn't coreboot anymore. Architectural changes happen in<br>
>>> chipset specific code instead of moving coreboot as a whole (after an<br>
>>> open discussion). Also, most of the positive aspects about coreboot are<br>
>>> lost.<br>
>><br>
>> Purely business commentary: In order to develop a competitive laptop<br>
>> on recent hardware one needs to include the features that consumers<br>
>> expect. Intel also ties those features inside of FSP, but FSP has a<br>
>> responsibility problem. It has traditionally attempted to do things it<br>
>> should not. FSP should be a library of sorts, but it has things in<br>
>> there it shouldn't. I mentioned some of this on the CL itself about<br>
>> our usage of SkipMpInit. It trying to take over resources that it<br>
>> shouldn't (among other things).<br>
>><br>
>> What architectural changes are you referring to? And what is your<br>
><br>
> You've got me there. I meant architectural things, not changes. Like<br>
> that patch on gerrit. It doesn't seem to be Intel specific, I also<br>
> can't find any soc_ reference in it. Yet, it's pushed to soc/intel/<br>
> and to me that looks like somebody wants to sneak it it (without big<br>
> discussion / being thought through for all of coreboot).<br>
><br>
>> definition of coreboot (I know see you wrote it below :)? early<br>
>> firmware that will initialize everything in open source for Intel<br>
>> platforms? I wish that were the case, but it's not something that is<br>
>> allowed by Intel currently. I'd love to see more granularity in FSP,<br>
>> but as noted in the CL commentary Intel hasn't been accepting of my<br>
>> suggestions for making things more granular such that one could do the<br>
>> only things that are deemed 'super secret' by Intel. The muddling of<br>
>> responsibility and lack of granularity are the current result.<br>
>><br>
>>><br>
>>> Of course, it's hard to argument about whether something is coreboot<br>
>>> or not without a clear definition of coreboot. But let me get this<br>
>>> one straight: It's definitely not coreboot just because it happens on<br>
>>> coreboot.org.<br>
>>><br>
>>> I'll try to sum up what is coreboot to me, and compare that to a current<br>
>>> coreboot with FSP. coreboot<br>
>>><br>
>>> 1. is free software<br>
>>> 2. is open source<br>
>>> 3. is auditable<br>
>>> 4. is lean (less code means less bugs)<br>
>>> 5. gives control to the user<br>
>>><br>
>>> but with FSP:<br>
>>><br>
>>> 1. You can not fully adapt it, you can't even just download it (often<br>
>>> have to steal the FSP binary):<br>
>>> 0%<br>
>>> 2. Comparing the sizes of open-source parts and FSP, maybe 30%. But<br>
>>> if you don't count open-source code that is only needed to handle<br>
>>> blob issues, rather<br>
>>> 20%<br>
>><br>
>> Is this 20-30% coreboot/open source of the total? Were you counting<br>
>> the edk2 stuff in there? A lot of the bloat in FSP comes from open<br>
>> source edk2.<br>
><br>
> You can't count EDK2 into it. Once it's built into FSP, it's not open-<br>
> source any more (unless somebody proves what parts match a reproducible<br>
> compilation of the open-source code). And for an open-source experience<br>
> you'd still need means to adapt these EDK2 parts in the binary. It was<br>
> just a wild guess based on my experience with Kaby Lake FSP (~500KiB),<br>
> and guessed 200KiB coreboot.<br>
><br>
>><br>
>>> 3. If you are backed by a huge company or government, you can audit<br>
>>> coreboot+FSP (I guess), if not than not, 50%? But given that the<br>
>>> size of the whole package is about 10 times the size of a clean<br>
>>> implementation, you have to audit 10 times more code (of much<br>
>>> poorer quality), thus at most<br>
>>> 5%<br>
>>> 4. 0% (see above)<br>
>>> 5. That seems to be my only point that Intel cares about. Still,<br>
>>> coreboot compatible binaries are often not available. You need<br>
>>> very weird workarounds if the one setting you miss is not there:<br>
>>> 50%<br>
>>><br>
>>> Numbers are just educated guesses, but might match reality. If you<br>
>>> average these, you'll see that coreboot+FSP is only 15% of (my)<br>
>>> coreboot. I would estimate that you can get up to 20% with the<br>
>>> design of FPS2.0.<br>
>><br>
>> I agree with the overall assessment above. As currently<br>
>> deployed/supported FSP is not really geared to people who don't have a<br>
>> more intimate relationship with Intel. It's been brought up numerous<br>
>> times, but it's Intel's decision to make a better product.<br>
><br>
> Right, quality of their products is up to them. But isn't it our re-<br>
> sponsibility to decide whether they can do that (15%) in the name of<br>
> coreboot?<br>
><br>
> Nico<br>
><br>
> [2] Assuming that the BWGs don't contain the secret ingredients, even<br>
> an NDA offer to all coreboot developer's (both hired ones and indi-<br>
> viduals) could help. If Intel allows to derive open-source code from<br>
> it (e.g. after a private review on gerrit) people would have less<br>
> doubts about signing an NDA, IMHO. Just a random thought; anything I<br>
> can come up with atm seems to be better than the status quo.<br>
><br>
>>><br>
>>> So it's time for an FSP3.0 that was designed with the community,<br>
>>> I'd say.<br>
>>><br>
>>> Best regards,<br>
>>> Nico<br>
>>><br>
>>> [1] <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__review.coreboot.org_-23_c_coreboot_-2B_25634_&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZmeYWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s=_TJ-Ft6l7FJJmJ1VJ-GJJfSzItat6lK0i15bv5BNSl0&e=" id="LPlnk801257" class="OWAAutoLink" previewremoved="true">
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.coreboot.org_-23_c_coreboot_-2B_25634_&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZmeYWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s=_TJ-Ft6l7FJJmJ1VJ-GJJfSzItat6lK0i15bv5BNSl0&e=</a><br>
><br>
> --<br>
> coreboot mailing list: coreboot@coreboot.org<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZmeYWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s=OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e=" id="LPlnk886953" class="OWAAutoLink" previewremoved="true">
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZmeYWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s=OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e=</a><br>
<br>
-- <br>
coreboot mailing list: coreboot@coreboot.org<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZmeYWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s=OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e=" id="LPlnk261578" class="OWAAutoLink" previewremoved="true">https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZmeYWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s=OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e=</a><br>
</div>
</span></font></div>
</div>
</body>
</html>