On 06.11.21 23:40, Martin Roth wrote:
>
> Nov 5, 2021, 14:10 by [email protected]:
>
>> On 05.11.21 18:58, Martin Roth wrote:
>>
>>> This binary is also mandatory for the elkhart lake platform, so to support
>>> this platform, loading this is required, whether it's built from source as
>>> a part of the coreboot build or supplied as a blob.
>>>
>> That's not true. Just rumors?
>>
> This is what was reported by the intel representative in the leadership
> meeting. I can't say whether it's true or not, this is however what was
> reported.
The current notion seems to be that the PSE firmware is not needed to
boot an EHL SoC, however is needed to make use of all its integrated
peripherals (e.g. the PSE related ethernet MACs).
>
> If it's optional though, then why do you even care, just don't use it and
> default it to off. If other people want to be able to use it, why are you
> concerned about preventing them?
I already gave some reasoning in the quote you dropped with this mail.
Related: Somebody found a marketing page of Intel that literally states
that the coreboot community does their support. Anyway, here's another
attempt:
The coreboot.org frontpage states about coreboot:
Fast, secure and flexible OpenSource firmware
When something is pushed into our repository that looks like the *exact*
opposite, I am naturally concerned. FWIW, some of the blob infrastruc-
ture that was bluntly added over the last few years made coreboot slow,
insecure and inflexible. At some point this has to stop. Otherwise,
I fear, we'll be run down by other projects eventually, while we
crawl under the blob pressure. IMHO, coreboot's biggest advantage used
to be the reasonable code base that provided a very nice development
experience. I guess we still do much better than EDK2, but how does
it look like compared to Project Mu? (I don't know actually, never
looked into it) Should we really throw that advantage away?
Sorry, now I feel like I derailed this thread :-/
>>> The decision at the leadership meeting was to allow this binary to be
>>> loaded by coreboot, so long as the PSE acts like an EC, and does not have
>>> access to the X86 memory space.
>>>
>> The discussion happened under a false pretext and with outdated
>> information. Also, the PSE is nothing like an EC. Hint: does an
>> EC do parts of the SoC silicon init that would usually be done
>> by our ramstage?
>>
> Then you shouldn't be worried. It was decided to accept it *so long as the
> PSE acts like an EC* as i said above. If that's not actually the case, then
> Sheng won't be able to show that it acts like an EC and there's no issue.
> Though if it's actually optional, again, what's the issue?
I'm sorry. I must have misinterpreted your email. You replied below my
quoted words, so I assumed that your mail is related to them. But I
couldn't find any clear message and assumed that you are opposed to
what I wrote. Sorry if that was a misinterpretation.
One issue left, I guess, it seems people want to go on with the patch
without showing anything about being EC like or about the security
implications. Maybe because the leadership decision wasn't clearly
communicated?
>
> What is it that it does that's normally done by coreboot's ramstage?
As far as we know so far, the PSE is the only processor core that can
access all the registers of the related peripherals, like the MACs
mentioned above. Some of these registers need to be written as part
of the silicon init, just like all the PCI drivers do that we usually
have in ramstage. So it's like a detour one has to take to do ram-
stage's job.
The PSE can do much more than that.
>
>
>> Maybe to avoid wasting time with premature decisions, we should
>> make up some guidelines? For instance, first discuss something on
>> the mailing list, then in the leadership meeting? This way people
>> could at least get a little information before they make decisions.
>>
>
> There are lots of options here:
> - There's an agenda that's posted before the meeting. Other things do come
> up in the meeting, but this item had been posted for at least a week before
> the leadership meeting, so there was plenty of time to look at it and decide
> whether or not to come.
> - People who believe they have information to share or want their opinions
> heard can come to the leadership meeting. If they aren't there, they don't
> get to voice an opinion in the meeting.
> - People can respond to the meeting minutes when they're posted to the
> mailing list or look at the minutes in the document.
Well, the minutes weren't very clear. Your mail from yesterday was the
first time I heard about a decision.
>
> Ultimately, the decision about the direction that the coreboot project is
> going to go is decided by the coreboot leaders, currently Stefan, Werner, and
> David. Sure, discussions can happen on the mailing list, but the leadership
> meeting is where the decisions get made.
There seems to be a gap when decisions are made but not communicated.
It doesn't feel like the leadership actually cares if their decisions
are honored.
>
> I've added your suggestion about requiring discussions on the mailing list to
> the meeting minutes of the next meeting. If you'd like to discuss the idea
> in the meeting, please attend.
I'll try.
>
>
>>> The load method wasn't discussed beyond what's in CB:55367, so if there's a
>>> different load method that's desired, that could be acceptable, but I think
>>> we can close the discussion on whether or not to allow the binary loader to
>>> be added, provided Sheng can show that this part doesn't have security
>>> implications for the X86 side.
>>>
>>
>> Interesting point about the security. I'm also curious. I couldn't
>> find anything about the mentioned MMU in Intel's docs.
>>
>> Nico
>>
>
>
>> PS. Please have a look at the available documentation before making
>> decisions.
>>
> And again, the decision was made conditionally upon the information we were
> given. If you want to voice concerns, please come to the meetings.
Well, not all people have weeks to waste. In such a scenario should I -2
a patch and wait for the next meeting? and if that's not conclusive wait
for the next? It doesn't seem fair for the authors.
So please, coreboot leadership, take part in the project, please attend
the mailing list. At least when you decide something, just send an
email. :) The mailing list is the only place where everyone gets a
chance to attend equally.
Nico
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
