Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Disabling Intel ME 11 via undocumented mode

blog.ptsecurity.com

Post reply on HN
Print view View original

21–30 of 228 posts

Re: Disabling Intel ME 11 via undocumented mode

#21

Post by tux3 »

lima wrote: post #10
dmitrygr wrote: post #5

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 :)

As soon as it's documented, you have to support it.

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.

Re: Disabling Intel ME 11 via undocumented mode

#22

Post by dfox »

arkainW123 wrote: post #9

I really can't grasp the "undocumented mode" term. I believe It was created on request.

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.

Re: Disabling Intel ME 11 via undocumented mode

#23

Post by ajross »

dfox wrote: post #22
arkainW123 wrote: post #9

I really can't grasp the "undocumented mode" term. I believe It was created on request.

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 to be part of the CPU core for compatibility with software written to work on the AT.

Re: Disabling Intel ME 11 via undocumented mode

#24

Post by ajross »

tux3 wrote: post #21
lima wrote: post #10

Earlier quoted context omitted.

As soon as it's documented, you have to support it.

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

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

Re: Disabling Intel ME 11 via undocumented mode

#25

Post by dmitrygr »

codezero wrote: post #20
dmitrygr wrote: post #5

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 :)

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

Re: Disabling Intel ME 11 via undocumented mode

#28

Post by equalunique »

valarauca1 wrote: post #19
baybal2 wrote: post #11

Earlier quoted context omitted.

>even before US embargo'd Intel from china You can see how well this embargo works in every electronics mall

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.

I wish there were OpenSPARC super computers in the US...
Post reply on HN