Google Even Fear Intel ME, Reduce Their Attack Vector With NERF

[starshipeleven]

Not sure how many cards need SMM and the likes,

SMM is a CPU feature reserved as CPU firmware, which is why they are either trying to disable it or giving full control of this feature to the embedded Linux kernel that is replacing the higher functions of UEFI.

Because even a Linux kernel inside there... it would need upgrading after time.

They made loud and clear that their main goal is to reduce dramatically attack surface, this kernel will be extremely cut down and limited, it won't be able to do most security-critical operations anyway (like say packet routing or firewall, and whatever, as it is just a smart-ish bootloader) so it won't be affected by bugs in these subsystems.

Complexity brings new attack vectors / surface.

That embedded linux kernel will be cut down as fuck, as it's there only to provide bootloader and network boot, and then dies after it has booted the system through kexec.

How often do you see firmware updates?

This isn't supposed to replace UEFI as vendor-provided firmware.

This is supposed to be a Coreboot 2.0, so you can update it if the board is supported.

They don't remove 100% ME nor 100% UEFI as they are still required for board initialization, and getting information to support a board without UEFI is not easy, so they just nuke and replace anything that is talking with the outside world with u-root embedded Linux firmware thing that acts as a bootloader-shield that can be updated regardless of the lower level blobs.

[jabl]

This is supposed to be a Coreboot 2.0, so you can update it if the board is supported.

It's not "Coreboot 2.0". Somebody asked roughly that at the Q&A after the presentation, and the presenter (Minnich (the creator of coreboot, FWIW)) answered that no, it most definitely isn't the "next generation" coreboot. If possible, coreboot is his preferred approach, but the problem is that the early boot stuff on modern Intel x86 server platforms is very tightly controlled with hardware signing keys, no datasheets whatsoever etc. Which is why coreboot hasn't been able to support anything newer than the P4 based Xeons, the last generation before quickpath was introduced. Minnich expressed doubts as to whether they'll ever be able to support those newer Xeon platforms with proper coreboot. Incidentally, this is also why they're not able to completely disable the ME, as on modern Intel platforms it's actually the ME that initializes and turns on the main CPU.

Thus NERF is a pragmatic compromise, as it leaves the original early boot firmware in place, and replaces the higher levels of the firmware stack (in his own words, "this gets us back on the server"). Furthermore, the interface they're using is actually stable and documented in the UEFI spec, as that's the one that all those 3rd party firmware vendors (AMI, Phoenix, whatever) code against. Due to using this documented higher level interface he was somewhat hopeful that they'd eventually be able to support EFI hw more generally, without requiring board-specific work like in coreboot. But we'll see about that I guess, it's still early days.

[starshipeleven]

It's not "Coreboot 2.0".

Well, his definition of "next generation" coreboot may be more strict than mine, but I meant the same thing.

Coreboot's main goal is/was replacing board firmware to give you more freedom/security/control over the system, and NERF seems to be designed for carrying the same torch in the 21st century, with current board firmware limitations.

I think NERF as imagined does technically provide a Stallman-approved system, as the blobs doing the board initialization are in flash and don't need to be updated anymore since they are completely isolated from the outside world, while the "smart" part of the board firmware is some kind of Linux embedded system which is FOSS.

[Luke]

Google is right about this one: I so distrust both Intel and AMD management engine/PSP so much that if my Bulldozer system dies I will either replace it with another AMD FX Bulldozer (pre-PSP socket AM3) system, or roll back even farther to an existing Phenom II system I have around. I will not be buying Ryzen until someone publishes a way to disable the PSP that works-and it would have to be cheap enough to risk bricking the board.

The UEFI network stack on the newer boards also forces non-use of onboard networking, possibly forcing use of a USB network device kept unplugged until the machine is booted, plus locked wifi for which the UEFI never gets the passphrase.

For used non-management engine boards, AMD stuff does go a lot newer than Intel, with both Phenom IIx6 and Bulldozer/Piledriver as viable options. The latter uses a lot less power at idle even though it is a power hog at full load.

[jpg44]

Its good to see Google develop this. Hopefully it will be made available for everyone to easily install, for us peons too who nevertheless deserve good security. Intel ME and anything like it (ARM doubtless will get it too), is simply a poorly conceived idea. There needs to be a direct path from the OS to the DVD drive without any other software in that path. This way, if the OS is compromised, there cannot be installed a firmware rootkit that can intercept attempts to reload the OS from DVD. Security should focus on better security layers in the OS, such as filesystem overlays, versioning filesystems, app sandboxes, executable signing on Linux, using managed code/VM languages in apps ,apparmor type rule based access control, etc.

[madscientist159]

Shameless plug, but OpenPOWER / POWER9 and Talos II already offer a completely open and auditable firmware stack at Intel/AMD -competitive performance, plus a host of other completely owner-controlled security features. If you're not using a data-slurping proprietary software stack, perhaps switching architecture is a good idea instead of playing cat and mouse with the ever-increasing DRM-type hardware on x86? (And if you are using a proprietary stack, trust me, the ME/PSP is the *least* of your worries...)

[Luke]

Shameless plug, but OpenPOWER / POWER9 and Talos II already offer a completely open and auditable firmware stack at Intel/AMD -competitive performance, plus a host of other completely owner-controlled security features. If you're not using a data-slurping proprietary software stack, perhaps switching architecture is a good idea instead of playing cat and mouse with the ever-increasing DRM-type hardware on x86? (And if you are using a proprietary stack, trust me, the ME/PSP is the *least* of your worries...)

Unfortunately, not everyone can afford a $1,000+ proc, much less the board it runs on. Old shit that predates UEFI is another story. For what one of these POWER system costs, you could select a board and proc known to be coreboot or even libreboot compatable, then scour computer shows building a long-lived stockpile, probably a lifetime supply. As I've said before, old systems that don't support hardware DRM are going to be like legal (or maybe illegal?) guns with no serial numbers. The BIOS board and to a lesser extent even pre-PSP AMD UEFI boards are our equivalent of the 80% M16 receiver that anyone can buy and finish with no paperwork.

Of course, if you don't get and stay the hell off of Facebook (and yes, Google as well), and don't block all of the ads, all of the trackers, and boycott all of the sites that break when you do this, none of this will do you any good in the world.

[madscientist159]

Unfortunately, not everyone can afford a $1,000+ proc, much less the board it runs on.

Not sure whre you got this info, but a single POWER9 processor is only a few hundred dollars. Stockpiling old computers only works if your computing needs remain static; how useful again is a C64 when cell phones are ubiquitous in society?

[Adarion]

The whole system offered by Raptor computing systems was very pricey. Maybe you can obtain some form of Power CPU for less, but the CPU without the board and all the stuff around won't really help you. And you'll want to have a vendor who provides you with a libreboot implementation for some board, I guess only few here could do this on their own.

Check this
https://secure.raptorcs.com/content/.../purchase.html

This should be their cheapest bundle, and the 2400 USD do not feature (register-ECC) RAM or a PSU or even a case. So you'll have to add a good amount of dollars to obtain something you can even power on.

[chithanh]

Correction, people asked them to make the PSP code open source, not remove it. Some AMD Product Manager named James said that they have talked with Lisa Su about it (the CEO) and are considering it, but told us that it would take a long time. We have not heard anything about it since.
Considering how long it has taken for them to open source their vulkan implementation though, I wouldn't hold my breath.

https://www.reddit.com/r/Amd/comment...other/dekwva9/

Actually, there is an answer since then, and it is much worse than a simple "no":

AMD said that they don't plan to open source PSP, and that instead they give the code to 3rd party auditors. As if that were in any way an adequate substitute. Coupled with the fact that their driver team apparently does not see security as a priority, that doesn't shed a good light on the company. At all.

https://www.youtube.com/watch?v=UMzXMvOaTZk