Live data from Hacker News

Disabling Intel ME 11 via undocumented mode

blog.ptsecurity.com

41–50 of 228 posts

Re: Disabling Intel ME 11 via undocumented mode

#41
post #23
post #22

Earlier quoted context omitted.

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 combi…

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…

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)

Re: Disabling Intel ME 11 via undocumented mode

#42

Earlier quoted context omitted.

> 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…

$50 or $100 for turning off the spyware in my own CPU is hardly reasonable.

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.

Re: Disabling Intel ME 11 via undocumented mode

#43
post #39

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 giv…

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.

Intel's management and QA probably looked only at UI where the flag is marked as "Reserved".

Re: Disabling Intel ME 11 via undocumented mode

#45
post #42

Earlier quoted context omitted.

$50 or $100 for turning off the spyware in my own CPU is hardly reasonable.

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.

Re: Disabling Intel ME 11 via undocumented mode

#46
post #34

Earlier quoted context omitted.

Yes, the AMD Platform Security Professor. The CEO said in a Reddit AMA they would look into open sourcing it.

They aren't going to: https://news.ycombinator.com/item?id=14803373

This makes one wonder if there is a secret legal requirement for this kind of capability.

Re: Disabling Intel ME 11 via undocumented mode

#47
post #45
post #42

Earlier quoted context omitted.

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.

Re: Disabling Intel ME 11 via undocumented mode

#48
post #41
post #23

Earlier quoted context omitted.

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…

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…

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)

Re: Disabling Intel ME 11 via undocumented mode

#49
post #32
post #26

Earlier quoted context omitted.

Thw article also mentions removing some non critical binaries and modifying the ME filesystem

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.

Re: Disabling Intel ME 11 via undocumented mode

#50

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?

Voiding patents probably doesn't change anything because patents usually contain just vague description.
Post reply on HN