[coreboot] Why do we have FSP-S

[Zoran Stojsavljevic]

Nico (Huber),

> So it's  time for an FSP3.0 that was designed with the community, I'd say.

You talk (in this email, at least) too much. :-))

I wish you a Good Luck. You'll need it (all the luck in this and
others' Worlds). And much more than that! Even Captain Jean-Luc Picard
(Star Trek Next Generation) and as extras Kathryn Janeway (Star Trek
Voyager) could not help you altogether/jointly with your requests! ;-)

Peace,
Zoran
_______

On Sat, Apr 28, 2018 at 3:16 PM, 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 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?
>
> 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.
>
>
> 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.
>
> 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%
>   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.
>
> 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: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot