This is why I support Power/MIPS/RISC development going forward. It's just a shame that we allowed intel and amd to both put in cpu backdoors at such an obvious level (I like x86 but it's not the cpu of the future unless it's open). I highly suspect some national security letter type shit is going on in the background, ala Promis and William A. Hamilton who has claimed on Bruce Schneiers blog they (intel agencies) were infiltrating even low level chip manufacturers. Danny Casalaro's death was likely a required nastyness to keep it covered up.
If some other CPU architecture were the dominant PC platform, do you think it wouldn't grow such features too?
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.
I read statements like this often on HN, but not once during my years of work as a sysadmin in enterprise IT in different countries did I meet anyone who used ME/AMT for employee laptops. Also not at conferences.
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.
Admins used the "Intel System Defense Utility"[1] back in the vPro/AMT days. It allowed for "nice" BMC-like features for normal desktops and laptops. I know about it from "The Website is Down"[2], but I find it hard to believe that nobody used it.
Are there any enterprise-useful features provided by ME that couldn't be provided external to the CPU?
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).
First, because of undisclosed design and patents it is difficult for competition to compete in the x86 market.
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.
The pinebook (aarch64 machine) has an opensparc1000 in exactly the same capacity as the intel ME. The firmware blob is out and people have poked at it, but the functionality has yet to be reproduced in open software.
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.
> because they are heavily promoted as a security/safety feature,
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.
It seems to me that the alternate vendor argument does not make sense. If we do not trust Intel, then there is no reason at all to trust any of the other vendors. Intel might actually require infiltration or an order; most of your smaller chip would add backdoors for cash (and in contrast to intel, a little cash would make a huge difference in their bottom lines).
According to their videos, their most recent chips are made by TSMC, but the older ones are made in Russia (I believe these are used for war applications). When the Russian factory switches to a better fab process, they'll also use it for modern chips. Indeed, the Russian factory is not theirs, though, as they are fabless.
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.
That's a good point. Big countries can afford to fab their own chips; small countries cannot. This has geopolitical considerations: The best option for a small country may be to decide which of the big countries it wants to be an ally or puppet of.
Incidentally this is one reason I think the UK is daft to leave the EU.
I’m not sure where you got the idea that such things only exist on x86 and shame Intel and AMD for a feature that’s useful for many scenarios. Have you considered the fact that such features exist because there are actually many customers that want it? I was literally using the counterpart of ME on Power today. These tools are essential to many enterprise workloads, especially when you are in Boston and your data center is in Chicago. I wouldn’t write a useful feature off as a conspiracy for surveillance just like that.
Then let owners control whether it's enabled or not (by a hardware switch if necessary). As it currently stands, I can't imagine a benign reason that would drive intel and AMD to lock users out of their machines.
You can't think of any reason? Have you or do you work for a large company [1], especially hardware companies? I've sat through I don't know how many "planning" meetings, which were little better than design by committee, and whose outcome was not in the best interest of the customer despite the best intentions of everyone there.
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".
While I too wish it was able to be disabled easily, I'm surprised the parent poster is getting down voted. Having worked for hardware companies, and chip companies in particular, I can very easily see the benign answer being that this isn't even on their radar as something to do. That they are providing the ME features because Sales Guys say that some big enterprise customers want them, and once it was designed in, there wasn't a convincing proposal to make it an optional / opt-in feature, because there simply isn't someone on the engineering team who is voicing the concerns of the "home PC user who cares about this-kind-of-thing."
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.
Nobody (aside from the US Government, obviously) really cares enough to buy hardware without a management engine, so why put the effort into writing and testing a configuration that a tiny segment of the population will use? (Also, Intel AMT contains some functionality that is actually used by the OS in everyday use, and turning it off would break that.)
Speaking as a naive outside observer, I am excited with the rumors that Microsoft and Apple will be making a move toward ARM in the nearish future. I don't think ARM is the answer (dear god give us riscv) but I see it as a step in the right direction away from closed systems.
They added it for business reasons for remote monitoring and control since enterprises like it. That's a large part of their sales. It also had consumer benefits. Related tech also helped DRM machines through Trusted Computing alliance. And they probably got defense contracts or payments for selective use by NSA or other organizations.
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.
Wouldn't it just take a motherboard maker or two to find an alternative to the PCH, like Nvidia nforce or a VIA chipset. adopt something like openbmc and sell it as an open feature? No intel PCH, no Intel ME. Seems like the Linux kernel is eager to support it: https://lwn.net/Articles/683320/
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.
I'd love it. But it probably would increase the manufacturer's costs for the motherboard (including engineering, component costs, etc.), distract the organization (managers, engineers, purchasing personnel, etc. spending time on this novel tech instead of just buying Intel/AMD chipsets), reduce quality (can they really compete with Intel's engineering resources?), which increases support costs, etc. ... all for a market that unfortunately is too small to measure.
The consumer market might be small, but the enterprise market would be what it is. I can't imagine openbmc being more expensive than a builtin wifi card with an external antenna connector for basic features. Features like RDP would be more off course. I imagine they could take a similar embedded processor and slap openbmc on it and market it as open just fine. The fact is, no alternatives to Intel PCH exist, so doing this isn't even an option. If Nvidia nForce or a VIA chipset existed for the newest Xeon with similar capabilities as the PCH minus the Intel ME, would you really doubt that there wouldn't be some motherboard maker that would go this route?
VIA used to make dual socket server class chipsets, for the pentium 3, which ever age was in.
They've supported a lot more than that for a very long time. The BMCs on both my ThinkServer TD340 and ProLiant ML10 support remote KVM access, CD/DVD emulation (mount a local .iso as a virtual drive on the server), firmware updates, and quite a bit more.
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.
I agree but those are servers, where the extra investment is worthwhile (server outages cost much more than a user desktop) and market demand is driven by people like you and me. I was talking about end-user desktops and laptops.
Right, out of band management (by today's definition) means - assuming the chassis has power and network, you can manage the machines, this is primarily a hardware problem. As much as I root for Open Source software, I don't see how OSS can replace the AMT stack.
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.
> As much as I root for Open Source software, I don't see how OSS can replace the AMT stack.
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.
Nonetheless, our research team (Dmitry Sklyarov, Mark Ermolov, and Maxim Goryachy)
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.
If ME is not a backdoor then why doesn't Intel allow to disable it? Why don't they publish detailed descriptions? Why don't they allow user to run their programs on ME CPU?
Where is the suggestion that Intel ME isn't a backdoor? The article states:
> 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.
> 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.
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.
Sure it's unreasonable, but at least charging for it would be better, and make more business sense, than the current "Fuck You, Plebe" they offer to us prisoners of the FVEY panopticon.
You are seeing this wrong. Intel has two reasons to have ME:
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 can be useful for other purposes too, for example for enforcing DRM so that DRM code runs on a ME engine. And of course DRM code can be backdoored too so playing a specially crafted video would run code from it.
Intel ME is not an effective DRM scheme. You need to be exceptionally careful when you mention DRM, because if it becomes commonly believed that Intel ME could be used to implement DRM all of a sudden the DMCA comes into play. Research into Intel ME vulnerabilities becomes a federal crime.
> because if it becomes commonly believed that Intel ME could be used to implement DRM all of a sudden the DMCA comes into play
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. [0] 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).
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.
The good-faith requirement also means that likely you could not publish a way for someone to disable the "effective anti-circumvention measure". Even if you could, anyone who used that research to disable their own devices is arguably not conducting "good faith security research". While researchers might be safe, nobody will be able to use the results of their research legally except the companies that produce DRM (so that they can make it more secure). I don't think that's actually an improvement to be honest.
> because if it becomes commonly believed that Intel ME could be used to implement DRM all of a sudden the DMCA comes into play. Research into Intel ME vulnerabilities becomes a federal crime.
This is rather an argument against DMCA or an argument why researchers working in this area should consider leaving the USA.
All signatories to WIPO have DMCA-like laws (including the "effective anti-circumvention" clauses). Given how many countries are signatories to WIPO, there are very few countries where it would be strictly legal to do research into "effective DRM schemes".
All signatories to WIPO have DMCA-like laws (including the "effective anti-circumvention" clauses). All countries with "modern" copyright laws are signatories to WIPO, so I would not put money on it being legal in the UK.
If ME isn't a backdoor why did Russia and China start efforts to surplant Intel with locally sourced processors (even before US embargo'd Intel from china)
For the same reason the government requires chips made in the US for Classified uses. If a fab is in another country there is always the possibility that the design could be compromised. Even shipping chips internationally can cause this concern as the chips can be swapped out. This isn't exactly a new concept... Russia did this to the US embassy a long while back http://www.cryptomuseum.com/covert/bugs/selectric/
We know that Amazon had Intel create custom chips specially for them, like the E5-2666 v3. So of course Uncle Sam have their own top secret bespoke Intel SKUs.
Amazon buys a significant fraction of the chips produced by Intel. I don't know how many security-sensitive chips the US government needs, but I'd be willing to bet it's a drop in the ocean.
Mostly the same chips everybody else does, but made in a special purpose fab in the US. This extends to everything in a computer (even firmware etc.). This means that a computer for use in classified settings is a LOT more expensive than your average desktop.
Why wouldn't they? It seems like Westerners believe in comparative advantage to the point they can't imagine wanting local competitors to other countries' most successful monopolies.
It isn't a blanket sanction, just against government and computing centers. The last 3 chinese super computers have used home grown FeiTeng RISC processors which were binary compatible to Itanium, but for new models their using OpenSPARC.
> The last 3 chinese super computers have used home grown FeiTeng RISC processors which were binary compatible to Itanium, but for new models their using OpenSPARC.
I don't understand what the SPARC "front end" actually is, but the Tianhe-2 Top 500 figure comes from Intel processors <https://www.top500.org/system/177999>.
Well, there are half a dozen SPARC systems in the Top 500, most notably <https://www.top500.org/system/177232>, with substantial longevity and currently top place in the HPCG benchmark list. They reflect needs in my area, at least. See also Fujitsu's M series?
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.)
You are describing "register renaming". And it's what everybody discovered was a better idea than putting "specific tasks" to registers with windows, banks, etc.
OoO register renaming is a nearly orthogonal concept compared to SPARC style register windows. And I say nearly, mainly because if you try to implement both it increases the complexity more than you would think due to microarchitectual interactions between the two concepts.
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.
Still it does work. It's may not prevent foreign government for getting electronics, but it increase costs significantly and kill local commercial companies in that market.
Every supported configuration paramater adds to the cost of supporting the platform, so, I totally get reducing the surface of supported parameters and charging whoever really needs this[1] through the nose for a custom support plan...
[1]: 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.
don't forget the microphone, and the speakers (ultrasonic exfiltration)
and the display (ISTR a fairly reproducable van eck attack in the last few years?)
and the cpu (various research on elliptic curve extraction by monitoring CPU power draw using off the shelf SDR equipment)
Rather than assume anything nefarious on the part of the USG, I'm willing to bet a buck that someone in the USG asked the right questions during contract negotiation, which is why this kill switch was added but not publicized to anyone outside participants in the HAP Program.
The more details leak about ME the more shocking it becomes. Why is this accepted in any free democratic society?
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.
This is just a footnote in the decades long trend away from ownership and the right to repair towards control and magic.
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.
> And even if one does not want to accept it what are the choices given similar technology is now integrated in other processors?
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[0]
- 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.[1]). I think they'll get there in the end![2]
- 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![4]
None of these is projects is ideal, but by supporting them you're enabling people who care to keep working on the this problem.
"There can be discussions, there can be debates ..."
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."[1]
> Why is this accepted in any free democratic society?
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.
Has it ever occurred to you that just perhaps - we do NOT live in a free democratic society? The USA has a whole caste of untouchables - and I don't mean the ostracised. Just look at how surprised they were that Trump got elected. In a "free democratic society" this would have been a "so what?" moment.
The company I founded built something very similar to a titan equipped server to allow attestation/measurement/signed logs/full external policy. I can tell you point blank that while the product we built is great, getting enterprises, the majority of whom ___still___ haven't patched eternal blue to worry about clean source, log traceability, etc. can be quite a challenging business at times. They don't understand problems with IPMI or anything else.
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)?
The interesting question here is: why undocumented. It was created on request, but nobody was told. Who pushed so hard ME to be on for everything but them? And why? We know the answer :)
Honestly? Chips are full of undocumented commands. It's really, really annoying.
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.
Intel's response to the authors kind of explains it: they added this feature hastily to meet specific requirements of the HAP program and didn't fully validate it – so it's not supported.
You missed the point. It was added for people with big money. I promise you - it is supported. Just not for you. You need to be backdoorable. They don't
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.
This sort of microcontroller for bringup and/or power in a large processor/SoC is not surprising at all. Intel ME is used for large scale setup and provisioning of new machines and is probably worth every penny to their OEM customers.
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.
> In retrospect they were kind of naive not to make it much harder to enable this HAP mode
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.
Old versions did. Newer ones, as mentioned in the article, use a 486-derived low-power core (similar to what was used in Edison/Quark platforms) for the ME.
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.]"
Not wanting to support it is a strange argument for not documenting it. I am not surprised that they're not documenting it, but not for this reason.
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.
> Not wanting to support it is a strange argument for not documenting it.
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.
This is something I always have been wondering about. I can't imagine the US government is happy having the ME in every computer, with a closed source operating system running that has complete access to CPU, memory and network. If anybody can call Intel and ask for a custom version without this stuff, it is the government. And it looks like they did.
(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 :-) ?
Considering that they left the HAP flag in the open and even commented it in an XML file; considering how it does not disable all of ME, but only certain bits; and contrasting it with the otherwise inscrutable, encrypted, and tamper-proof nature of ME, it's hard not to see it as a honeypot or bait.
TL;DR: Intel put a special High Assurance Platform (HAP) mode in ME for the US government. If toggled on, it disables all non-critical ME functionality. Questioned, Intel responded:
> 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.
Historically, high-assurance security used a mix of commodity and custom hardware. SCOMP had IO/MMU plus type enforcement at memory & storage level. Congress mandated use of commercial off-the-shelf which forced ports to insecure architectures. Aesec's GEMSOS, one of first security kernels, did some kind of custom firmware when ported to x86. Paul Karger, one of INFOSEC's founders, decided on VMM's for easier security & legacy compatibility with modifications to PALcode. Many products, like INTEGRITY-178B, targeted PowerPC to get better hardware with cross-selling to aerospace. General Dynamics with NSA modified Intel stuff with misnamed HAP (Linux + VMware aint high assurance). Others are doing custom CPU's and firmware designed for security whereas Joshua Edmison made attachment that reuses high-performing CPU's.
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.
basically govt finally learned about ME (like VNC built into CPU) and said "what?! are you kidding!?" and on second breath - "keep it on for everybody else though!"
>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.
AMT is a piece of software that runs on the Management Engine. vPro-enabled platforms are the ones aimed at business laptops and workstations, not consumer stuff. It's important to make the distinction because people can check, find that their machine doesn't have the VNC functionality and then assume that they don't have anything to worry about as far as the ME goes, which is a false sense of security.
i don't think you described the behavior of typical HN reader :) Anyway, vPro with VNC seems to be present on all consumer (ie. with IGP) CPUs, so there is nothing to worry about in the sense that one anyway can't do anything about it, and thus the worrying is futile.
No, it's not. AMT is only shipped on Core-series CPUs when they're accompanied with the business chipset rather than the consumer chipset. It's not an integral part of the ME, it's software that the OEM has to license and ship in their firmware.
Can someone explain simply what this means for projects like libreboot and coreboot? I'm always interested with this stuff and it's implications, but don't have the background to understand a lot of low level details. Is the verdict still the same or are we gaining ground? Last time I checked, purism was quite optimistic about it, but the libreboot website seemed really pessimistic about it.
I imagine coreboot might integrate this functionality or recommend that people using coreboot do so themselves, but libreboot won't, because the entire point of libreboot is to only use entirely free software and the ME firmware (even the stripped down version that obeys this disable bit) which is required to boot the machine is not free.
I wonder if Apple is ok with this. They usually don't like someone's else software running on their machines, especially on such a low level. They will probably negotiate a kill switch for them too.
> I wonder if Apple is ok with this. They usually don't like someone's else software running on their machines.
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.
Years and years ago, when color printer/scanners were fairly new, I tried to scan and print a $5 dollar bill. I was curious. The machine printed out about a third of the image but the rest of what it printed was a very official looking notice to please call the US Treasury.
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
I'm one of the most paranoid people you're ever likely to meet. (People more paranoid than I am won't communicate online.) Printer stenography is just beyond the limit I set for myself to try to disbelieve, and yet, here it is.
(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 wrote off freedom and privacy 2 years ago simply because it was having adverse effects on my mental health. I wasn't changing anything by being paranoid so I just stopped being paranoid.
I still don't use facebook and I run free/open-source software exclusively, but worrying about it didn't change anything.
i feel you, mate. even more troubling for me is that ppl, including snowden, believe he changed things. well, more ppl use encryption. but the vast majority doesnt even know. ppl are still too stupid to grasp the concept of privacy and freedom. its just some pretty words. like "i want my children to have better future" and off they go posting pictures of them on facebook.
"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”)'."
Recently I saw a guy in a cafe with a General Dynamics laptop. It looked ruggedized and a few years old; I don't know if it was an HAP system. He said he got if off of eBay.
What I consider as "interesting" is the fact that much more research (at least if you look at HN headlines/posts) goes into "Intel ME" vs. "AMD Secure Processor" (formerly known as "AMD PSP" ("Platform Security Processor")). I really don't want to badmouth this important research on "Intel ME", but I am a little bit confused from this asymmetry.
Could somebody explain in layman terms what exactly (say, 'spy-wise') ME could enable some parties to (remotely?) do with one's pc? And what are the chances this actually is being done?
They could put in a backdoor that opens when a magic packet is passed. These things exist[1]. Your cell phone likely has one in the radio[2]. The problem with this existing, other than the privacy issues, is that the packet can eventually be discovered by fuzzing[3] the hardware.
My understanding is this step isn't really a necessity but rather was done to prove that ME could be disabled at an extremely low level since the missing binaries would no longer trigger what's effectively a failure condition.
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.
I'm simply intrigued how this bit has managed to elude so many developers and hackers over the years. It's literally an option in an intel software tool, and yet you have people who have vehemently complained about Intel ME for the past few years. I have some serious cognitive dissonance going on right now.
The latest version of ME, 11, uses a x86 processor. That's why the researchers were able to perform this analysis and find the bit to flip. It also doesn't disable ME, just most of it.
> I'm simply intrigued how this bit has managed to elude so many developers and hackers over the years.
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:"
ACPI is almost as horrible: complicated, opaque, untrusted code running on a VM instead of using declarative data tables.
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.
Well said. It also makes computing much more expensive and slow to progress. But those fraudsters love their violence-backed monopoly. Image if a few vital manufacturing plants were destroyed, we would have silicone shortages. We have made ourselves fragile, backwards and weak.
What happened to 3rd party chipsets? Seems like VIA, ALi, SiS, Nvidia nForce, all stopped making them for Intel processors around 2008. If there were alternative chipsets still around, we would see more motherboard makers adopting something like openBMC with an alternative chipset and using it. No Intel PCH, no Intel ME.
If there were alternative chipsets still around, we would see more motherboard makers adopting something like openBMC with an alternative chipset and using it.
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.
That is not an apples to apples comparison. Plenty of features differ from motherboard to motherboard. Someone like an ASUS could adopt openbmc much easier if an alternative chipset existed. I'm not arguing about the marketability of openbmc, I know it exists. I'm talking about why there are no chipset alternatives to Intel PCH that would force Intel ME on us.
If the EU or US regulators can force Google and Microsoft to unbundle and provide APIs, surely unbundling chipsets fit in the same category. Making chipsets was a successful business for quite a few companies, too bad the FTC didn't force Intel to provide enough documentation, like it mandated the number of PCI-E lanes.
Now if the NSA got to the FTC, that would be different.
Q: How does one actually determine intel ME is present in a CPU... I've got an old P8600, I can find no definitive list of CPUs or ways to test for it. Some articles say all intel CPUs since 2006, others say only the newer "core" brand.
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.
On the bright side, older MEs are easier to de-fang. The 06-08 versions can sometimes be removed entirely.
That is pretty much standard term for processor features that are not supported by Intel. The main selling point of the whole Intel's x86 platform is that when something is supported and documented it will either behave the same way on newewr processors or newer processors would include some mechanism to emulate the old behavior. Intel tends to go especially overboard with this approach and even support feature combinations that are not useful in any way.
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.
Just to clarify: the A20 stuff was an IBM PC/AT feature in the chipset of the original machine, not a CPU thing. It was actually a response to an Intel mistake in backward compatibility between the 8086 and 286 (real mode segments that pointed "beyond" the first 1MB would wrap around on the original processor but hit the second megabyte on the 286).
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.
The mistake was with the fact, that 8086 has 64kB-16B worth of user visible memory addresses that are beyond what the harware could actually address due to width of the physical address bus and thus got aliased to the other end of address space. People say that there was software that depended on this behavior, but I can't see any sane reason why somebody would write something like that (given how the address layout of PC looks like the only sane application of this aliasing is in the early initialization BIOS code, which obviously had to be significantly rewritten for 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)
You're arguing semantics. Pulling the cache on-chip means that the memory bus and its mapping logic needs to be on-chip too, because it sits beneath the cache. We're saying exactly the same thing.
(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)
I know we are saying ecactly the same thing, but somebody else who reads this threads might not, so the successive clarifications are useful :)
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.
"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."
In fact it is CPU thing since x86 CPUs have on-die caches, because the masking has to happen before the access hits cache.
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).
I think that depends on what you mean by good and computer. You might, for example, want something that costs on the same order of magnitude as an Intel or AMD x86_64-bit cpu. Afaik the answer to that question then becomes no.
Thanks. I couldn't find LEON (bad google-fu?), can you link?
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.
Imagine if some non-US government voided Intel and AMD's patents as a self-defence measure against these probably-backdoored 'features'. Why should they protect the profits of hostile corporations?
