Most hardware has evolved to effectively run the main OS under a sandbox where it "thinks" it is in control, but isn't.
A nice talk on this: https://www.youtube.com/watch?v=36myc8wQhLo
I don't think this fact is what you should focus on. That fact the blobs are binary, closed, proprietary, signed but not easily verifiable by the user, and not easy to disable is the problem.
The promise is they're going to "improve security for PCs." Yet, they're using techniques that we know to be invalid. There's no reason to tolerate this.
Unfortunately there isn’t really incentive for Intel to do this, unless larger companies / governments refuse to run IME-enabled chips due to security concerns.
That it can be used to back door the machine is the primary use case for the audience, as that is what lets them do a remote reinstall of Bob’s broken workstation somewhere, or any number of other legit use cases.
Governments do you use public internet VPN sometimes...via accredited boxes which handle the tunneling for them and are the one point of ingress (and have a commensurate price tag).
Which is to say, all they want from their suppliers is "yeah, ME is safe. Also buy these tools to manage your fleet."
There may be good arguments for allowing these types of "features" but this is not one of them. I'm so tired of seeing "it's fine because everyone else is doing it too"
Like mentioned elsewhere in this thread, the problem isn't the presence of these types of components, but how opaque to the user (read: highly technical user) they are. Also they exist because there is demand for their features.
The talk I linked makes the case that OS development is failing by pretending these co-processors are outside its scope, and hardware vendors just go and do their own thing on the side. I add that this incentivizes proprietary firmware instead of open one. I mean, if there were pressure (from paying customers) for Intel to support open-source IME firmware, they'd do it. After all, they just want to sell more chips.
Because $$$ talks, and there's a lot of money in media.
What I have learnt (to my dismay): Complex hardware has their own software, like IME, but they do important things you can't turn off. The danger in this: hardware-based exploits. In other words, the security of an OS is irrelevant if there is some shoddy closed-source software on your system running hardware components. Linux already has lost the control of hardware. It's like virtualization, but on the hardware level.
People talk about switching off the IME, but that's barking up the wrong tree.
What's proposed: redesign hardware and write an OS encompassing all hardware functions. Don't accept opaque SOCs where your OS is just an API consumer.
This is controversial because of course DRM components want to be a black box, for example.
If I am wrong, please point out. I would be happy.
And you seem to have misunderstood me. It's not about Apple locking something, its about Apple software on the hardware of your Asahi Linux system.
Their coprocessors are not higher-privileged. On the contrary, they are all isolated from AP, each other and main memory (by IOMMU).
My issue last I worked with one was that userspace was ridiculously restricted - they have made it antagonistically difficult to do anything on a Mac. Normal PC, despite the nonsense in the hardware, remains fairly easy to work with, as long as you aren't doing security critical stuff.
https://www.runzero.com/blog/ilo-vulnerabilities/
I'm not sure that iDRAC is much better; haven't checked lately.
It's one thing to have it, but if it sits out of my reach, sorry hoss, I just don't trust you that much, and the fact you and your buddies all do it and are the only shops in town doesn't make me feel any better.
In order to have network access, Intel Management Engine is not enough, it does not have full network access at all. You need Intel AMT (also marketed as "vPro"), and that one is paid extra. With CPUs featuring such support being separate SKUs, so you would definitely know -- and you can check in ark. You also need to pair it with Intel ethernet or wifi, any other network interface is not good enough.
So here you have it, your separate class of processor.
And when you look at server hardware the have completely different backdoor facilities.
It really looks like pure pretext, especially since there isn't just a simple bios option to comprehensively and completely disable it.
How come Intel get away with it?
I went ahead and i disabled it
It's like phone lines, Intel agencies loved being able to arbitrarily tap lines, at least until they started having their own lines tapped as well.
If I were China or Russia I'd have stockpiled a couple bugs in these backdoors and I'd be waiting to cause major economic disruption to the US govt with their own systems... so then it's just a game of who can knock out the other's comms first (which is as I understand it doctrine generally speaking in conflict, but)
From the article posted by OP
>sets the 'High Assurance Program' bit, an ME 'kill switch' that the US government reportedly[11] had incorporated for PCs used in sensitive applications[12][13];
[11] links to a dead website, but it makes you understand the US called dibs on disabling it
The disproportionate hate is a good thing, if you ask me.
Its just that even that talk vastly underestimated just how many microcontrollers exist on a modern machine.
In the past those controllers were isolated to a few areas (disk controllers, higher end network cards), but the drive over the past decade+ for more efficient devices and "universal" packetized buses (ex PCIe, USB), has sprinkled them in places simply to monitor utilization and adjust bus clocks, as well as packet scheduling and error/retry logic, etc, etc, etc. I was reading about some of the latest m.2 NVMe controllers a while back and IIRC there were something like a half dozen independent Arm's just inside the controller. The last fully open disk stack on a PC was probably an MFM/RLL controller in the mid 1980's.
So, while I would love if the manufacture of every little USB device or whatever published the full register documentation, firmware listings, whatever, that ship has long sailed. The worst part isn't looking for the piles of scattered SPI flash eeproms on random boards, its the integrated "Secure" sides of these devices which happen to be all but invisible. None of that is going to be documented anytime in the near future. Every single one of these companies hides their "secret sauce" in the firmware of these devices, be that how to minimize latency on a NVMe device, to how to get maximum throughput on a wifi chip, to how to increase a DRAM controllers power efficiency. In some of these cases, the firmware probably isn't even that special, they are doing basically the same thing as every one of their competitors, but you will never get them to admit it.
So, imagining that an "OS" can control this mess like a 1960's mainframe is nonsense. Modern mainframes don't even control stuff at that level anymore.
So like software abstractions, we have hardware abstractions which provide higher level constructs for low level software to talk to. Be that something like XHCI where the system talks to generic endpoint queues and a processor does all the low level packet building/scheduling or its something like the tiny integrated cores making decisions about which parts of a CPUs clock and power domains need to be dynamically enabled/disabled for a given perf/power profile and the OS talks to generic firmware interfaces to set policies. To even LBA disk layouts which abstract away all the details of flash channels, COW, wear leveling, NAND error correction, bit pattern sensing, page/block erase sizes, etc.
In the end, if someone wanted to actually work on this problem, the first step towards open hardware isn't really building a RISC-V system, its building competitive NIC's, keyboards, USB controllers, etc, etc, etc with open hardware designs. What we have today is like linux, everyone wants to work on the kernel, no one wants to maintain old crufty code in Make. So, in the end swapping an x86 for a RISC-V doesn't give you more open hardware if its still got its own management processors tied to the same closed hardware IP for literally everything else in the machine.
But co-processors that can break OS' assumptions (regarding security, for example) sound like they should be under OS control. Not that this means under control of a single kernel but, at least, under control of some set of components that are developed together.
Actually it's building the software tools to emulate these, USB is a dense standard, you will have more luck emulating a working USB device first pass before building out the supporting infrastructure.
Once you can emulate/design your open chip computer, then you can start doing test runs/production runs. The market for such a thing will be limited to engineers and tech enthusiasts, at least until some hardware tech startup starts outcompeting the other players on the market.