On 06.11.21 23:40, Martin Roth wrote:
Nov 5, 2021, 14:10 by nico.h@gmx.de:
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