It's not hard to imagine an alternate universe in which we all have RISC workstations with the equivalent of ME, and Intel/AMD are the minorities who have more "open" CPUs without, but only because they hadn't grown enough.
The underlying reason why ME became popular is the same reason why proprietary walled gardens became popular: because they are heavily promoted as a security/safety feature, and "who doesn't want to be safe and secure?"
Remember that, shortly before the turn of the century, Intel was convinced by the masses to remove a feature that would seem almost innocuous today, a serial number, but only because they marketed it as for DRM/identification instead of a security feature:
... is also because it provides management features that are wanted by enterprise customers. If you're running hundreds of servers in a data center, the more management you can do remotely, without visiting the machine room and preferably automated as much as possible, the better.
This is quite irrelevant and even undesirable for an individual's personal computer.
Admins use the ILOM/IPMI for servers, so you don't really need it for server CPUs. For laptops all management happens at the operating system level, not below it.
Since the boot process already involves some amount of hand holding from outside the CPU, any of those features could have been provided by a designed-for-enterprise motherboard with ME-like features in the BIOS/UEFI or even some sort of peripheral in the PCH (or wherever).
Scott McNealy, Sun Microsystems (1999):
"You have zero privacy anyway. Get over it."
Wow! And look where we are now. Quite the irony how things played out.
Second, competition is exactly what we need to get rid of hardware backdoors and unwanted features. If I had the coice to buy a PC without closed firmware and hardware, I would do so. The more open, the better. We direly need competition there.
It could be an open solution too. I have only cursory followed OCP and other hardware advances, but this being used with Raptor's power servers. Opensparc before Oracle, and recently the RISC V community might have built something similar too.
You can build such features without baking the keys into the hardware. You can have an open security module where changing the key simply makes everything that has been previously secured by it unreadable. That way a user can load his custom keys and firmware if he wants to. You can cascade that dependency down the secure boot chain by mixing some secret from the module into the HDD decryption for example.
Only vendor lock-in (e.g. windows RT) and DRM require hardcoded keys.
I'm all for national governments making their own hardware not subject to backdoors installed by other national governments, but there's a huge difference in capability between Russia and, say, Lebanon.
Incidentally this is one reason I think the UK is daft to leave the EU.
1. Or the government or one of it's contractors. I've even sat through meetings 12 engineers sat around and argued about what to name something internal. I started calling this "name by committee".
And even if there is, the "non-evil" reason for keeping this as is might be that "enterprise customer doesn't want something that is easily disabled, and we can't justify cost of a separate design / fab run for a small minority of customers", vs. "Haha, now we have a backdoor into EVERYTHING!"
(Hell, even the proposals about disable via hardware switch, or having the ME on a separate component probably boil down to money. To an outsider, hardware companies are funny beasts in that they really start caring about things like counting pennies and minimizing BOM cost as much as possible. I've been in worried meetings where we were literally counting and debating pennies, and wondering how I got there, but it makes sense at a company level since those pennies add up when you are building thousands or millions of something! This may have boiled down to "motherboard manufacturer doesn't want to have to put another mechanical part on the board, and they are looking to buy a shitload of our parts, let's keep them happy")
Please note: I'm not saying, or even advocating, that this is a good thing, or results in ideal outcomes when I say "benign". I'm just using it in the sense that this likely wasn't a malicious decision, but probably one motivated by money at some point, by people who didn't necessarily see the harm in it.
Lots of return on that investment. Lots of reasons unrelated to those you mention.
There are opensource ways to do out of band management without it.
>consumer benefits. Related tech also helped DRM machines through Trusted Computing alliance.
Nobody I knew who was knowledgeable wanted that shit in the first place. It was always edging away consumer control of the platform. DRM is part of the problem here! Same thing with web standards. What annoys me the most about this is the audacity of calling it "consumer benefits".
>probably got defense contracts or payments for selective use by NSA or other organizations
Fine, but that's not a good enough reason to backdoor literally everything for everyone else. (reminds me of systemd and redhat actually)
> There are opensource ways to do out of band management without it.
I'd be surprised if there is a cost-effective open source alternative to this requirement: Remotely access and control a computer under any circumstance where it has power and a physical network connection. Solutions like AMT work even if there is no functioning processor or memory, because ME provides its own processor and memory. The open source alternative would need the same hardware.
At best, it would mean the corporate IT department designing, buying, installing, integrating, and supporting additional hardware, for tens of thousands of computers. That's very hard to justify when the computers come with hardware already installed, integrated with everything else, and supported by the vendor.
If someone could put FOSS on ME (or competing proprietary solutions), I'd be all for it. I suspect it would be very difficult, as we can't even figure out how to disable ME.
What happened to 3rd parties making chipsets? Another case of Intel abusing it's monopoly?
Seems like they mention chipsets, but didn't go far enough given what happened to Nvidia chipsets vis-a-vis GPUs. They could do a little bit better as a regulator.
VIA used to make dual socket server class chipsets, for the pentium 3, which ever age was in.
The cost of IoT devices supports what you are saying.
On top of that, I should note they do this without assistance of the Intel ME. The remote KVM access is handled through a video adapter embedded in the BMC.
Our team has several racks of R&D servers 7500km away from the bulk of the team, and having OOB management is vital. Absolutely vital.
The claim that extant FLOSS solutions can stand in for AMT was false, but now the replies to that have set up a false dichotomy.
The opposite of a monstrously complicated, buggy proprietary interface with undocumented features is a compartmentalized, robust proprietary interface with a fully-documented public interface. "Sorry, we don't want to show you the design specs for our hardware." "Sorry, we don't want to show you the code for our secret sauce." That's fine. Just give the bits that can be flipped to slide all the way from maximum ease like your R&D use case to maximum lockdown like a Bitcoin-based service.
SPARC has been open for years FYI.
Dmitry Sklyarov! There's a name I haven't seen in a while... good to see he's still actively doing this stuff.
The immense complexity of the base firmware and hardware in a modern system is astonishing. XML, MINIX, and three(!) complete 486 cores in the PCH.
Given this amazing feat of engineering, and the goals of the ME, it makes me wonder what people would be willing to work on it --- "making the nooses on which to hang ourselves", as the saying goes --- and if perhaps some of those people are actually not too approving of the idea and would, given an opportunity to do it without consequences to themselves, do a Snowden and leak everything that they could...
The fact that such an "ME killswitch" exists doesn't surprise me either; in this case it seems to be an actual feature, but putting such functionalty into debug/test modes is not uncommon. It was only a matter of time before someone would find it.
Or maybe the people who work on the ME realize that it's far from the largest risk in the system.
Firmware pays pretty damn well. If you know what you're doing.
> In this article, we describe how we discovered this undocumented mode and how it is connected with the U.S. government's High Assurance Platform (HAP) program.
> Googling did not take long. The second search result said that the name belongs to a trusted platform program linked to the U.S. National Security Agency (NSA).
>We believe that this mechanism is designed to meet a typical requirement of government agencies, which want to reduce the possibility of side-channel leaks. But the main question remains: how does HAP affect Boot Guard? Due to the closed nature of this technology, it is not possible to answer this question yet, but we hope to do so soon.
Interesting that Intel will provide this to the US government for enough money, but wouldn't offer it as an additional $50 or $100 option for end-customers to disable the ME.
I think there are probably enough privacy conscious people who would be willing to buy a Skylake or newer platform from Intel if they could easily disable the non-BUP components of the ME for a reasonable fee.
1. It is useful in business settings
2. It enables the US spy agencies complete surveillance of all PCs
It's the second point that explains why they can't make it optional. And that makes business sense. That way they ensure backing from the NSA, instead of having to fight against them.
It is already common knowledge that the ME is used to implement DRM.
The DRM functionality of the ME has been discussed in several books.  The ME contains DRM functions to securely decode content (e.g. streaming video) in a way such that decoded content cannot be snooped by the host processor before it is displayed to the user (ostensibly via a secure channel like HDCP).
The PAVP module is part of the ME firmware. Which means the management engine is, among other things, a DRM implementation.
https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf (page 17)
Of the four criteria in the exemption, I wouldn't put it past the government trying to make the case that exposing a NSA spy program somehow falls afoul of good faith investigation - but the general view that "any DRM research is a crime" is no longer accurate.
This is rather an argument against DMCA or an argument why researchers working in this area should consider leaving the USA.
(Though it is somewhat more limited than the DMCA.)
You can see how well this embargo works in every electronics mall
Where did you get that information?
https://en.wikipedia.org/wiki/SW26010 doesn't claim any of that.
These turned out to be not such a great idea.
I've read that x86 has multiple registers (eg, https://news.ycombinator.com/item?id=9264195, http://blog.erratasec.com/2015/03/x86-is-high-level-language...). "You want to do something with rax, so the processor grabs one of its 168 internal registers to play the role of rax for a moment" sounds like a type of register-window implementation to me. Or I'm completely misinterpreting the term.
Note that my sentiment/tone in asking this is "huh, if that's the case then POWER and other architectures could really compete with x86!". (Assuming POWER doesn't use that approach.)
Of course, IBM knew about this way back.
Those who do not study history are doomed to repeat it.
Also, it's not really an x86 thing (for instance most Atoms don't have these extra registers), it's an in-order vs out-of-order thing. Most Power cores do have the larger bank and renaming.
PS: read my profile description.
> You can see how well this embargo works in every electronics mall
IIRC, the embargo was only against very specific processors used in a specific supercomputer design.
: I'm not suggesting most, if not all, people don't need the ability to disable Intel ME, only that, they more often than not don't value it enough to pay for it..
Am I correct in assuming that since this backdoor chip has access to all of the peripheral I/O that it could even be used on a device with onboard wireless in "power off" mode, which is usually some kind of low-level sleep? So a compromise of this subsystem (or intentional backdoor) would allow one to take control of even a device that is "off". Given the trend to non-removable batteries, it might actually be impossible to prevent such an attack without physically destroying a laptop.
There can be discussions, there can be debates but in everyday life this is already accepted. And even if one does not want to accept it what are the choices given similar technology is now integrated in other processors?
If we accept that computers are essential to operate in modern society then this is akin to a company taking control of the water supply with the ability to stop supply and do other unknown actions with zero accountability.
If you expand this thought this is a kind of fascism. We could be left with a shell of freedom and democracy while the government in partnership with corporates take deeper control of day to day life.
Up until the 80s, anything you bought would, reasonably, provide schematics, diagnostic info, and at worst on request details on the original designs or how substitute parts would work in almost any mechanical system, including TVs. Phones were extraordinarily unique at the time in how proprietary they were, in that Bell Labs had a government monopoly until that decade that gave them carte blanche to not care about consumer satisfaction and let them extort people en masse both for money and never giving an inch of control in the PSTN.
Then computers happened, and they were sufficiently magical for a sufficient number of people to tip all of our society away from the autonomy to own things and know how they work towards having magical black boxes that seem to do what you want them to.
The Intel ME is just one aspect of this. Of how government will seize the opportunity to take advantage of the willful and tolerated ignorance of the people as a tool to spy on whomever they want.
This trend is also not even close to reversing. Cars made in the 90s were still fairly open, but introduced OBD computer systems that were proprietary black boxes of diagnostic info. Now, every new car is entirely computer driven, and that computer controls the whole vehicles operation in undocumented and proprietary ways. Talk to any garage that isn't a brand dealer - the newer the car, the less they can actually do to fix it.
This is applying to everything now. New tvs are now completely irreparable. Cell phones are holistically compromised and proprietary. New appliances all have proprietary computers in them. Your new house is built with proprietary computers that control the climate, the power, everything. If something breaks? You have to send it to the manufacturer I guess because you aren't allowed to know how it works or how to fix it anymore. Its "too complicated", is the excuse. Its the same excuse why the FCC is trying to cripple open source firmware on routers, or why ham radio and broadcast television are being sabotaged at every level of government.
People gave up trying to understand computers, to be able to treat them like any other machine they use - and break - in knowing how to fix them. And so governments and companies took full advantage of that yielding of knowledge and authority and now hold it over all of us as a tool of subjugation and exploitation.
Unfortunately, there are few, but alternatives are being pursued by a few different groups which you can support in various ways. In rough ascending order of time horizon:
- Minifree sell old ThinkPads, with old processors which predate the ME, and use Libeboot
- Purism use new processors, but do their best to neuter the ME, by buying processors with minimal remote control features, stopping the ME from being able to control the networking card, using and running Coreboot. They're working to use me_cleaner to completely neutralize the ME on new processors, but there's lots of work to do to fix bugs caused (e.g.). I think they'll get there in the end!
- Raptor Engineering are trying to fund a run of fully open POWER processors (less powerful cores, but loads of them). Avoids Intel altogether. Very large upfront costs.
- The RISC-V team at Berkeley are working on a new instruction set. Years before you can buy anything, but I'm sure there's a way to send them beer money, or apply to work there!
None of these is projects is ideal, but by supporting them you're enabling people who care to keep working on the this problem.
Can there be ?
If ME is part of DRM platforms (and I believe it is) then disabling it is circumvention of a digital copyright mechanism which brings the DMCA into play.
"The lawsuit against 2600 magazine, threats against Professor Edward Felten's team of researchers, and prosecution of the Russian programmer Dmitry Sklyarov are among the most widely known examples of the DMCA being used to chill speech and research. Bowing to DMCA liability fears, online service providers and bulletin board operators have censored discussions of copy-protection systems, programmers have removed computer security programs from their websites, and students, scientists and security experts have stopped publishing details of their research."
Likely because of good intentions lining the road.
It's my understanding that Intel ME is the basis for an anti-theft and recovery platform for laptops. Which is something that has always been of importance to portable device makers.
How do you think "Find my iPhone" works?
The only thing that is going to change the face of the security market is that the loop between responsibility and inaction gets closed; as things stand today, the primary difficulty in the space is that for your average, not-very-knowledgeable customer, there is effectively no difference in mostly fraudulent security solutions and real ones - both get auditors out of your hair, so why bother buying anything real (or even not deploying anything like Comodo which actually makes things worse but still checks the box)?
I've been working on getting small TFTs working, for example. Many of them use a common driver chip that supports your basic 8080 parallel interface. The driver manufacturer provides a datasheet documenting the various commands which it will accept.
So of course, to start the chip up, you need to send it a series of magic commands and data values which are not documented in the datasheet.
Adafruit was kind enough to explain the reasoning behind these values to someone who was presumably walking through the same steps as me to bring one of these screens up: https://forums.adafruit.com/viewtopic.php?f=47&t=63229
I guess that maybe it prevents people from buying secondhand stock and getting it working from just the datasheet, without involving the original manufacturer? Anyways, caveat emptor. Even when there's only one seller to emptor from.
I'm not an engineer experienced in this kind of work, but I fail to see how a company whose core business is manufacturing chips would develop an entire computer (comprising an x86 CPU, its own RAM, MINIX OS, and access to all kinds of I/O) hidden inside each one of their chips and made largely inaccessible to regular users and developers. Unless they are paid very well to do so.
In retrospect they were kind of naive not to make it much harder to enable this HAP mode, considering the lengths they went to make ME tamper proof. They left the flag wide open and even commented it in an XML file.
I'm not saying that the NSA isn't possibly using it as a backdoor, but to say that the whole ME subsystem was created because they were paid off by the NSA is a bit far fetched.
Idk... I suspect this info being publicized won't have much material impact on the effectiveness of the ME as a backdoor. Even among the tiny portion of the population interested enough and capable of understanding what it is and why it's bad, I doubt more than 1% of us will be bothered to go through the trouble of actually disabling it.
The ME runs an Argonaut RISC Core instruction set and leverages a lot of the existing infrastructure in the system since it sits directly in the chipset and can ask the main CPU to do some things on its behalf too.
For a general purpose consumer chip, "supported" generally doesn't carry the implicit caveat of:
"... if you bring your own hardware engineers, pay enough $$$ to be worth letting your hardware engineers talk to our hardware engineers, and coordinate with us so we can test your very specific hardware setup(s) instead of trying to verify compatibility with a wider range of motherboards etc."
You're of course correct that Intel is supporting it for $BIG_CUSTOMER that meets this exacting list (and likely more) of requirements. But I'd say codezero is just as correct in saying "it's not supported [for general use.]"
Their client — the Unites States Government — demanded this feature be made specifically for their internal use, so I would hope it is a pretty well supported configuration already.
Furthermore as it only seems to be disabling features rather than enabling new ones, there should be little support needed in the first place.
Anyone with the knowledge and equipment to go enable the HAP bit is unlikely to need any more support than the documentation itself.
Seriously, no. That happens all the time in all kinds of software environments. Someone adds a crazy hack in a product with an API. Do you add it to the API, even though bits of it may leak visibly into the stuff seen by the customer? Hell no. That's what happened here.
(If any important Silicon Valley CEO reads this, why don't you give Intel a call, as an important customer, and ask why 1) you can't disable the ME and 2) for a written guarantee that there is no backdoor in the ME?)
Something else: does anybody know if the trick mentioned in the article has negative side effects? Does power management still work? Can we be sure that this doesn't activate a backdoor to begin with, and the computer tries to connect to an NSA domain :-) ?
> In response to requests from customers with specialized requirements we sometimes explore the modification or disabling of certain features. In this case, the modifications were made at the request of equipment manufacturers in support of their customer’s evaluation of the US government’s “High Assurance Platform” program. These modifications underwent a limited validation cycle and are not an officially supported configuration.
So, there's a long history in high-assurance security of securing each layer. Mainstream security ignored it as usual until recently focusing on that stuff. Many smart folks among them are trying to secure software on backdoored CPU's while others (eg Raptor POWER, Cambridge CHERI) are trying to give us non-backdoored systems. At one point, I knew most of the latter since so few are working on that angle. Rarely fix root cause over tactical mitigations.
>AMT is part of the Intel Management Engine, which is built into PCs with Intel vPro technology.
>Currently, AMT is available in desktops, servers, ultrabooks, tablets, and laptops with Intel Core vPro processor family, including Intel Core i3, i5, i7, and Intel Xeon processor E3-1200 product family.
Oct 2012. Never forget.
I think that it's true that they want to have as much control over the experience as possible, but that is more from a perspective of being able to control the (visible parts of) user experience. I'd be pretty surprised if they didn't already knew/had an idea of what was going on with the ME and that there must be some way to disable it, but MacBooks don't receive the amount of attention required for them to care about this low-level detail, which 'doesn't affect' regular customers anyway.
The iOS devices don't use Intel chips and the Macs don't really need to.
Ironically enough, using an Intel processor with ME cleaner is more free than using an AMD processor.
(edit: HP was the manufacturer.)
Another item of interest may be printer stenography, in which every piece of printed paper, seemingly from every printer, can be traced back to make, model and potentially even the unit used to print it: https://en.wikipedia.org/wiki/Printer_steganography
(Meaning that I always assumed something like this was going on, because that's what I would do, but I try to disbelieve it so as to be able to act normal. I believe all phones are continually listening to and scanning their ambient environments, because that's what I would do. But probably not, right? Right?)
The thing that bothers me the most is that "normal" people refuse to engage with reality. I used to tell people some of the things e.g. that Snowden revealed, but I was always accused of wearing the tinfoil hat. From my point of view, normal people are hugely intellectually dishonest. Poor Ed Snowden had to throw his life away to try to get people to notice and think about what's happening, and typically all most people do is whine about their precious privacy (the ones that don't immediately stick their heads back into the sand that is.) Like privacy is something that still exists. It doesn't.
I better wrap it up here before I get the urge to talk about forbidden technologies like REDACTED, REDACTED, and REDACTED. I mean, there's a certain tension knowing about a REDACTED that can cure all diseases, but that cannot be popularized because it can also REDACTED without a trace. Could you imagine the chaos if something like that became public knowledge!?
I still don't use facebook and I run free/open-source software exclusively, but worrying about it didn't change anything.
To quote https://news.ycombinator.com/item?id=14803645
"AMD seems not to use the brand name "AMD PSP" anymore. Instead some years ago they began to use the name "AMD Secure Processor". Nevertheless it is just the same: Read the small footnote at http://www.amd.com/en-gb/innovations/software-technologies/s... which begins with 'AMD Secure Processor (formerly “Platform Security Processor” or “PSP”)'."
Some stuff is government only but some for businesses. You'll have to contact them to find out.
Could be wrong. Probably safer to just set the killbit rather than also tamper with ME directly is ultimately my point. That's my risk aversion at work.
Lots of hackers already knew that for many years - I would rather call it "common knowledge". But they had no idea what one could do to change anything about this. Just like "AMD PSP"/"AMD Secure Processor" - it is common knowledge that it exists, but we have no idea what it really does or how one can disable/disarm it.
Or baseband processors - you can be pretty sure that there exist backdoors. I always tell people that they should throw away their mobile phones and love to say that they are bugging devices with integrated telephony functions - in this order; and this is true even if we do not assume any evil backdoors - for those reasons I don't own one. But people don't care.
Or have you never considered why Intel pushed Wifi so much (Intel Centrino)? Doesn't Wifi (or "accidental" bugs in the chip firmware for it) look like a backdoor that can also be used over an air gap? If you need a further point on this: https://puri.sm/posts/hard-not-soft-kill-switches/ Why does the PCISIG M.2 NGFF standard require that a pin has to be pulled high do disable Wifi and Bluetooth? I always tell people that they should avoid Wifi and use ethernet instead. Also to no avail.
"Once the DID is received, BUP—depending on the mode, which is determined by various factors—either starts IBL processes from InitScript (in normal mode) or hangs in a loop, which it can exit only when it receives a message from the PMC, for example as a result of a request to restart or shut down the system."
But I am not sure if those are stopped:
"Secondly, it starts a whole string of processes; some of them are hard-coded (SYNCMAN, PM, VFS),"
Since the authors only mention that the InitScript/IBL Processes are not started, I assumed the hardcoded ones were started, but could be prevented from loading in the following way:
"2. In the CPD section of the FTPR, remove or damage all modules except those required by BUP for startup:"
Closed-source firmware and silicon must end, because it's impossible to authoritatively verify correctness or rule out malware implants inserted at some point along the way.
No we wouldn't. All the chipsets would be subject to the same market forces and thus would converge on similar features, including the ME. Just like how 99% of x86 systems are running UEFI instead of coreboot.
Big companies will do open consumer friendly products, once the ecosystem exists and there is some consumer awareness.
Now if the NSA got to the FTC, that would be different.
Intel's ME was first available in 2006, and by the end of 2008 it was on every CPU they produce.
According to ark.intel.com, the P8600 chip was produced Q3'08 so it's in the right timeline for having the ME. But the giveaway is that the chip has "Trusted Execution technology".
Intel® Trusted Execution Technology for safer computing is a versatile set
of hardware extensions to Intel® processors and chipsets that enhance the
digital office platform with security capabilities such as measured launch
and protected execution. It enables an environment where applications can
run within their own space, protected from all other software on the system.
Recent example is that original AMD's x86_64 CPUs did not support certain descriptor formats in long mode and didn't support x87 FPU ISA for 64b code. Intel's EMT64 supports both of these things. Usefulnes of first is somewhat questionable as only real user of that is dosemu, another would be if somebody would want to modify some Concurrent DOS/FlexOS derived OS to be 64b aware (there actually might be some small bussiness case for doing so). Microsoft solved this by droping support for 16b and DOS applications in 64b builds. And for the second limitation it is pretty obvious that there cannot be any code that would be broken by that.
Older examples are the whole A20M# business and then there is LOADALL, which was never officially documented, has three diferrent encodings and behaviors depending on CPU generation but got used by Microsoft and thus the 386 encoding and behavior is somewhat semi-documented and semi-supported even 30 years later.
But when the memory mapping went on-chip in later devices, it needed to be part of the CPU core for compatibility with software written to work on the AT.
Edit: the reason why 486 and later CPUs contain the A20M logic internally has nothing to do with "memory mapping". 486 has on chip cache which has to know, whether this memory region is aliased or not. Additional effect of this logic being in the CPU is that it can be controlled by writes into MSRs, which are significantly faster than sending commands into KBC which controlled this thing on AT. (Also, in vm86 mode this compatibility hack could be implemented by MMU without dedicated hardware cludges, which is what essentially all DOS XMS managers do)
(And FWIW: the mistake Intel made was that those accesses were legal on an 8086. They should have been an exception condition, which would have avoided this problem by making the 286 behavior a proper superset)
In hindsight, making accesses beyond the end of physical memory on 8086 an exception is nice solution. But I think that more useful solution would be different design of the 8086 pseudo-segmentation that would make such linear adresses unrepresentable on the user level. On the other hand whether this would be good idea depends on whether you view another horrible cludge (ie. HMA/UMB and potentially also usage of that as EMS window or bounce buffer) as useful.
Edit: as for the memory attached to processor behaving sanely it is interesting to look at Alpha which expects that memory is memory and could be write back cached. With one small and significant exception: the region on which ISA VGA would exist is hardwired to be uncacheable.
To quote https://en.wikipedia.org/w/index.php?title=A20_line&oldid=79...
"Support for the A20 gate was changed in the Nehalem microarchitecture (some sources incorrectly claim A20 support was removed). Rather than the CPU having a dedicated A20M# pin which receives the signal whether or not to mask the A20 bit, it has been virtualized so that the information is sent from the peripheral hardware to the CPU using special bus cycles."
So it is now a CPU thing.
Nehalem removed the physical pin for outside control of that feature (for the northbridge/southbridge platforms this involved a wire that went directly from CPU to EC/SuperIO connected to LPC or ISA, which is highly weird from architectural standpoint).
There's some hope around power9-based systems:
For more modest demands on performance, and affordability , there's LEON and OpenSPARC.
So in effect, big $CORPs own computers and with Alphabet agency influence and systemic flaws, the hope for open and secure and powerful computing should be forgotten.
> the hope for open and secure and powerful computing should be forgotten
I'd say it depends a bit. IBM still throwing money at POWER is interesting. The openSPARC is interesting for certain embedded applications that deal with signal processing - where there's real work to be done both in software and hardware (asic / fpga) - like wireless communication. Having a few sparc cores that run Linux well ready to drop in on a fpga is very nice.
But for consumer hw... Yeah, it's difficult to compete with arm on one side and Intel/AMD on the other. Remember that even transmeta had to throw in the towel trying to compete in that space.