4 ms·
This topic comes up a bunch still. Someone please correct me, but as I understand it anyone using new chips that use Intel ME (or AMD's equivalent) have a gapin
by loughnane 3y ago
This topic comes up a bunch still. Someone please correct me, but as I understand it anyone using new chips that use Intel ME (or AMD's equivalent) have a gaping hole in their security that no OS can patch.
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.
[0] https://puri.sm/learn/intel-me/ https://puri.sm/learn/intel-me/
- bri3d 3y ago> anyone using new chips that use Intel ME (or AMD's equivalent) have a gaping hole in their security that no OS can patch 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.
- loughnane 3y agoYeah, this lives in the back of my mind too. I run debian on 11th gen intel, but with the non-free blobs included to make life easier. I've been meaning to try it without them, but it's too tempting to just get things 'up' instead of hacking on it.
- mistrial9 3y agoDebian has been hacked by Intel's blobs from my point of view
- matheusmoreira 3y agoThere's little we can do about it short of running ancient libreboot computers. We'll never be truly free until we have the technology to manufacture free computer chips at home, just like we can make free software at home.
- voldacar 3y agoThere's the talos II, if you can afford it.
- tonetegeatinst 3y agoASML fabs in every basement when? I think riskV is as close to an open source CPU we have at the moment, unfortuantly most riskV cpu's rely on the company having IP that is protected like the CPU layout or the core architecture as of what I understand of modern CPU design. 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.
- YoshiRulz 3y agoRISC-V* (Reduced Instruction Set Computing, 5th incarnation) 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.
- Onavo 3y agoDoes Apple have a warranty canary? How do we know that the M series of chips haven't been compromised?
- adamomada 3y agomarcan of the Asahi Linux project got into a discussion on reddit about this, and says that when it comes to hardware, you just can’t know. > 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_most_open_x86_or_m2/jm7a6eb/ 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-Apple-Silicon https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
- wtallis 3y agoMost consumer products (as opposed to some of those marketed to businesses) don't have enough of the components in place for the ME to accomplish anything, good or bad.
- loughnane 3y agoWhat do you mean? What sort of components?
- wtallis 3y agoFor starters, few consumer systems have the ME wired up to a supported Intel NIC to provide the remote access functionality that is usually seen as the scariest feature among those related to the ME. The processors are usually not vPro-enabled models so the firwmare will refuse to enable those features due to Intel's product segmentation strategy. And even if all the right hardware is in place, I think a system still needs to be provisioned by someone with physical access to turn on those features. 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.
- charcircuit 3y ago>but as I understand it anyone using new chips that use Intel ME (or AMD's equivalent) have a gaping hole in their security that no OS can patch. 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.
- dylan604 3y agoAre these blob type of attacks accessible after boot? Essentially, are these only accessible if you have physical access? And at that point, isn't it game over anyways?
- bri3d 3y agoIntel ME allows intentional remote access through the ME in some enterprise scenarios (vPro). The driver support matrix is quite small and this is a massively overblown concern IMO, but it’s the root of a lot of the hand wringing. 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.
- aspenmayer 3y ago> 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. Can you elaborate and/or provide context/links?
- 3y ago
- sweetjuly 3y agoPeople always complain about ME/PSP but it misses the point: there is no alternative to trusting your SoC manufacturer. If they wanted to implement a backdoor, they could do so in a much more powerful and secretive way.