[coreboot] Why do we have FSP-S

[Zoran Stojsavljevic]

The magic formula to all this, INTEL improvement, is everything contained
in only one word: ARM64!

This is a very politically correct Civil Approach, don't you agree?! ;-)

Best Regards.
Zoran Stojsavljevic
_______

On Tue, May 1, 2018 at 1:46 AM, David Hendricks <dhendricks at fb.com> wrote:

>
> You are just, with this desperate chit-chat, fueling INTEL's big EGO.
> Please, continue to do so! INTEL, at the end of the day, will thank
> you for that! :-))
>
> 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.
>
>
> ------------------------------
> *From:* coreboot <coreboot-bounces at coreboot.org> on behalf of Zoran
> Stojsavljevic <zoran.stojsavljevic at gmail.com>
> *Sent:* Monday, April 30, 2018 9:58:33 AM
> *To:* Nico Huber
> *Cc:* Nathaniel L Desimone; Furquan Shaikh; Vincent Palatin;
> coreboot at coreboot.org; Aaron Durbin; Stefan Reinauer; Martin Roth; ron
> minnich; Shelley Chen; Julius Werner; Vadim Bendebury; Nick Vaccaro; Chris
> Ching; Duncan Laurie; Subrata Banik
> *Subject:* Re: [coreboot] Why do we have FSP-S
>
> Nico, Aaron,
>
> You are just, with this desperate chit-chat, fueling INTEL's big EGO.
> Please, continue to do so! INTEL, at the end of the day, will thank
> you for that! :-))
>
> Zoran
> _______
>
> On Mon, Apr 30, 2018 at 4:48 PM, Nico Huber <nico.h at gmx.de> wrote:
> > 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 <nico.h at gmx.de> 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://urldefense.proofpoint.com/v2/url?u=https-3A__review.
> coreboot.org_-23_c_coreboot_-2B_25634_&d=DwICAg&c=
> 5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZme
> YWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&
> s=_TJ-Ft6l7FJJmJ1VJ-GJJfSzItat6lK0i15bv5BNSl0&e=
> >
> > --
> > coreboot mailing list: coreboot at coreboot.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.
> coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c=
> 5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZme
> YWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s=
> OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e=
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.
> coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c=
> 5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZme
> YWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s=
> OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e=
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180501/ec362a0b/attachment-0001.html>