I know puri.sm[0] takes some steps to try to plug the hole, but haven't read up to see if it's effective or no.
Not really; anyone using chips with Intel ME or AMD PSP have an additional large binary blob running on their system which may or may not contain bugs or backdoors (of course, also realizing a sufficiently bad bug is indistinguishable from a backdoor).
There are tens to hundreds of such blobs running on almost any modern system and these are just one example. I would argue that ME and PSP are not the worst blob on many systems; they have both unsupported but almost certainly effective (MEcleaner / ME code removal), supported and almost certainly effective (HAP bit), or supported and likely effective (ME / PSP disable command) mechanisms to disable their functionality, and they are comparatively well-documented versus the firmware that runs on every other peripheral (networking, GPU, etc.) and comparatively hardened versus EFI.
RISKV has been a great step forward and I'd love to see it succeed but I'm also aware of the lack of open source architecture for GPU's or AI accelerators.
And sure, companies can choose not to share chip designs, but if you want an open-design CPU then you should be checking for that specifically and not just filtering by ISA. There exist such chips already, and I expect they'll catch up with AArch64 chips (in terms of being able to run desktop Linux) in <10 years, given the specs already include SIMD and the high-end chips have clock rates comparable to the oldest Windows-on-ARM laptops, like the 1st-gen Surface.
> I can't prove the absence of a silicon backdoor on any machine, but I can say that given everything we know about AS systems (and we know quite a bit), there is no known place a significant backdoor could hide that could completely compromise my system. And there are several such places on pretty much every x86 system
(Long) thread starts here, show hidden comments for the full discussion https://old.reddit.com/r/AsahiLinux/comments/13voeey/what_is...
I highly recommend reading this if you’re interested https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
However, onboard firmware based attacks are absolutely accessible remotely and after boot in many scenarios. It’s certainly plausible in theory that an exploit in ME firmware could, for example, allow an attacker to escape a VM or bypass various types of memory protection. Unfortunately the actual role of the ME is rather opaque (it’s known, for example, to manage peripherals in s0ix sleep).
Ditto for any other blob. Maybe a specially crafted packet can exploit a WiFi firmware. Maybe a video frame can compromise the GPU.
These are also good persistence vectors - gain access remotely to the NOR flash containing EFI, and you have a huge attack surface area to install an early boot implant. (or if secure boot isn’t enabled, it’s just game over anyway). On Linux, it’s often just hanging out in /dev as a block device; otherwise, once an attacker has access to the full address space, it’s not too hard to bitbang.
These are all fairly esoteric attacks compared to the more likely ways to get owned (supply chain, browser bugs, misconfiguration), but they’re definitely real things.
The closed-sourceness is only a tiny part of the problem, too - a lot of the worst attacks so far are actually in open source based EFI firmware, which is riddled with bugs.
Which takes me back to my original response to “isn’t everyone backdoored by ME” - sure, maybe, but if you’re looking for practical holes and back doors, ME is hardly your largest problem.
Can you elaborate and/or provide context/links?
For most consumers, the main valid complaint about the ME is that it's a huge pile of unnecessary complexity operating at low levels of their system with minimal documentation. Anything fitting that description is a bit of a security risk, but the ME is merely one of many of those closed firmware blobs.
The existence of security coprocessors is not a security hole and firmware updates to these processors can be released if a security issue was found.