Then you have to worry about any "management" modes on the FPGA.

https://www.cl.cam.ac.uk/~sps32/Silicon_scan_draft.pdf

What's left, RISC-V?

https://en.wikipedia.org/wiki/RISC-V

Not really, because most deployments use UEFI alongside them.

https://github.com/riscv-admin/riscv-uefi-edk2-docs

So if it isn't from door A, door B will do.

It is not just for booting. UEFI has Runtime Services that an OS can call.

How is UEFI like ME/PSP? I thought it was just for booting.

Its surprisingly more complex than that. You can run Doom in UEFI

https://github.com/Cacodemon345/uefidoom

Okay, but that doesn't really bother me; running arbitrary payloads is the point of a bootloader. The only reason I would be worried by UEFI on RISC-V is if the UEFI firmware in question stays running in the background after the OS boots, and isn't properly inspectable. That might be the case - I have some vague notion of UEFI providing post-boot services, and for all that the EDK version is FOSS you could certainly make a closed version - but I'm not seeing any reason to panic just yet.

UEFI can provide post-boot services, but only in the same sense that a DOS-era BIOS did: by providing memory-mapped code that UEFI applications can call into, exokernel style. The UEFI framework isn't a hypervisor; it has no capacity to have ongoing execution threads "behind" the OS kernel. Rather, the OS kernel just receives a memory+PCIe map from UEFI at startup that contains some stuff UEFI left mapped; and it's up to the OS kernel whether to keep it mapped and make use of it; or just to unmap it.

And no production OS kernel really uses any of the code that UEFI maps, or keeps any of said code mapped. It may keep the data-table pages (e.g. ACPI sections) mapped, for a while; but usually only long enough to copy said data into its own internal data structures.

(Which is a shame, actually, as an OS kernel that did take advantage of UEFI services like UEFI applications do, would be able to do things that modern kernels currently mostly can't — like storing startup logs and crash dumps in motherboard NAND space reserved for that function, to provide on-device debugging through a separate UEFI crash-log-viewer app in case of startup disk failure, rather than needing to attach a separate serial debugger.)

On X86/AMD64 there is also ACPI and SMM (System Management Mode), which overlap in parts. ACPI calls into code provided by whichever bootloader, running post-boot above to operating system, or behind its back, so to speak. It's complicated.

[1] https://en.wikipedia.org/wiki/System_Management_Mode

[2] https://en.wikipedia.org/wiki/Advanced_Configuration_and_Pow...

Mostly for dynamic powermanagement and voltage regulation, monitoring temperatures, hotplugging, etc. That's just the way it is (now).

I remember when this first made the rounds over a decade ago with some mainboards from CENSORED Apple supplier which were pretty usable, except when running under something else than Microsoft Windows. IIRC it wasn't malice, only implemented in a way which made this hard to interface with from Linux, or the likes. Of course undocumented. Later, but about the same timeframe the first so called open source/security 'zealots' damning ACPI in general for those reasons.

It may be called differently on other platforms, but similar/equivalent mechanisms exist on almost everthing which is not in a museeum or landfill.

In most computers with Intel/AMD CPUs, and especially in most laptops, the UEFI firmware remains running concurrently with the operating system.

Before giving control to the operating system for the first time, the UEFI firmware can configure various peripherals to generate SMI (System Management Interrupts) on various types of events and it can ensure that the SMI requests will be handled in the future by itself and not by the operating system. The UEFI firmware can lock this configuration, so that the operating system will not be able to change it.

When a SMI request happens, the UEFI firmware handles the event with the CPU in SMM (System Management Mode), which is a mode with more privileges than any operating system or hypervisor and which has access to everything, including to things that are protected from accesses by the operating system, e.g. a memory area reserved for SMM use.

The ARM CPUs may also have a mode equivalent with the Intel SMM, named EL3 (Exception Level 3), so, on ARM CPUs that implement EL3, the UEFI firmware can also run concurrently with the operating system or hypervisor, overriding them whenever it wants.

In theory, the UEFI firmware should use SMM only to handle benign events, for which Microsoft was too lazy to write handlers and Intel obliged by creating the ugly SMM, passing this event handling task to the motherboard manufacturers (forcing thus also the other operating systems to use the BIOS/UEFI handlers, even if they could have handled those events better themselves), such as powering up and down peripherals or changing the clock frequency of the CPU.

Nevertheless, the writer of the UEFI firmware could easily do much more than that, e.g. inspecting the content of the memory, the data written or read on storage devices or sent and received through the network. (Full memory, storage and network traffic encryption could prevent this.)

The SMM could also be used to implement a remote control of the computer that cannot be detected or prevented by the operating system, but for this an even more powerful facility has been introduced by Intel and AMD, many years later after SMM, in the form of the auxiliary CPU from ME/PSP.

A malicious actor can do a lot of things in UEFI, but they can't decrypt my disk, they can't boot into my OS, and they can't mess with my userland environment. If Johnny Blackhat fancies a game of Doom over TTY on my desktop's UEFI environment, he can be my guest.

POWER8 and POWER9 say hi.

Money says bye.

At least for AMD the PSP isn’t externally exposed which means the attack surface is drastically reduced.

When you say externally exposed, do you mean to the network, or physically exposed, or what?

It doesn’t sit on the network (unlike the ME) so an attacker needs to have access to the host already to be able to exploit any vulnerabilities on the PSP.

This is not about the management engine. Microcode is part of the actual core processor itself, but an updatable layer. One sort off correct mental model might be to think of x64 hardware as being a RISC-ish processor that runs microcode that runs your code.

What about POWER?

It’s not a backdoor until it’s proven that it’s used for that propose. Until the it’s just (yet another) potential side channel.

I don't understand that logic.

It's like saying I haven't been robbed until I discover that my stuff is missing.

> It's like saying I haven't been robbed until I discover that my stuff is missing.

Well, robbery is theft under threat of force, so it would be very hard to be robbed and remain unaware of it.

Yep, I assume they just don’t know the difference between robbery and burglary.

Actually, I do know the difference, but forgot the distinction when writing the comment :)

That's literally true, though?

To make the analogy work for you, you have to add something about doors being unlocked, or somebody else having the key to your home.

I think in the original analogy, the actual robbery is just used as an event which may occur without our knowledge. Your analogy is better, the mapping makes more sense.

Something like: The locksmith has made a copy of your keys without notifying you. They could hypothetically use those keys to enable a robbery, but you won't know definitively either way until you find something stolen. But it is a pretty weird thing for them to do, right?

>That's literally true, though?

There's no Schrodinger's Burglar. You've been robbed once I take your wallet, whether you've discovered it or not.