New subject: Why do we have FSP-S

30 Apr 2018

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

is free software
is open source
is auditable
is lean (less code means less bugs)
gives control to the user

but with FSP:

You can not fully adapt it, you can't even just download it (often
have to steal the FSP binary):
0%
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.
...
...

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%
0% (see above)
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/

Re: [coreboot] Why do we have FSP-S