"100% Free" GNU Boot Discovers Again They Have Been Shipping Non-Free Code

[Developer12]

I'm tired of listening to sobs and moans about how difficult everything is. Let's finish this.

Spoken like someone totally ignorant of the problems involved.

[cb88]

OK, good answer, but not sufficiently precise.
Because, something has to install the SMM interrupt handlers, and that would probably be UEFI, i.e. SMM interrupts are likely to be caught by UEFI code... and those are running while the kernel is loading...
And not to mention that, on Intel CPUs, the Management Engine is always running in the background... and the Management Engine is installed by UEFI...

All great ideas...

And on every AMD since bulldozer AMD Platform Security Processor is running... I am pretty sure AMD's is acutally baked in and not loaded by anything its a separate ARM controller that sits on the bus.

[phoron]

I didn't mention AMD just because I was not 100% sure about what is the current situation regarding PSP.
So, your answer is a digression, because it in no way contradicts what I have said.
Possibly, you wrote your answer just to chat with me.

Well, why not, let's have a chat.
As far as I know (I might be wrong):
(1) The PSP is not constantly running in the background (i.e. it might get called, or it might be hooked to some interrupts, but it is not "running")
(2) The PSP has no known network functionality (although we cannot be certain about this, until AMD open-sources it, which will never happen)
(3) The PSP code is loaded into RAM by AGESA, which itself is loaded by UEFI, pretty much the same as on Intel.
(4) The PSP is not a fully-fledged operating system with multi-threading capability, unlike Intel ME.

Not sure I should join the chat, or if it's off topic, I'll just drop a link (not very up to date), because I'm not very well informed but I think you're more or less wrong in the 4 points. Or at least it's not so clear.

[phoron]

I haven't (yet) found any information in your link that contradicts my point (4).

Well, maybe it doesn't contradict it. But it makes it somewhat moot.
If PSP is a processor, then it will run its own software, we can call it OS or not, but in my book a computer inside your computer is worse (or equal) than an OS below your OS.
And if it has access to all RAM, and veto on what software is run in the x86 cores, it doesn't need to be an OS, it can decide what OS the x86 runs and it can modify anything to change its behaviour. It can act as a BMC, more or less. Maybe it doesn't, but then it's because it hasn't been needed. Conceptually it could.

About point 2. The PSP has access to all the RAM and all the peripherals, including any network interfaces. It could update itself OTA if it needs to.
"it has at minimum MMIO-based access to the network controllers". So it's a matter of we not knowing the implementation, but if it didn't have network functionality today, it may have it in the next update.

[

Here is a question of mine: how do you update AGESA? I would presume that you do it via UEFI. So, I would presume that you can update AGESA without updating UEFI?

I believe AGESA is sort of a library for low level hardware initalization. It is run earlier on at x86 core 0 init. and possibly part of it on every x86 core. So it runs once the PSP has started and verified the ROM (UEFI, etc.) signatures. The BIOS/UEFI blob contains it, so it is updated when you update BIOS/UEFI (through linux fwupd or the UEFI menu itself maybe nowadays? or whatever windows has). I don't think it's an independent subsytem you update on its own, but more like a building block for your BIOS/UEFI. But maybe I'm not current anymore. I think of agesa as a source dump that people use to build their BIOS or UEFI firmware.

Please note I'm not sure of how all of this works.

[Espionage724]

SMM is evil.

Seemingly (iirc) doesn't work on my Coffeelake laptop after disabling Intel ME

[justinkb]

Something was accidentally working as a result. That just wouldn't do