Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

30 years ago you could buy an IBM PC/AT and it would come with schematics, detailed programming information, and the complete source code listing for the BIOS[1]. There wasn't really anything "hidden", and you really felt like "the sole owner of your PC". The PC became the dominant platform because of this. Now, because of corporate interests[2][3], much of it is officially under a thick layer of red-tape NDAs, and what little else interesting out there comes mainly from leaks (be thankful for East-Asian companies' insecurity...), and there are still plenty of things hidden away. On the the other hand, all of this stuff is documented somewhere; whether that documentation will ever see the light of day is the real question (for anyone reading this who does possess such information: please do the right thing ;-) Especially when it's far easier now than before to distribute lots of data, putting the complete ME programming documentation and maybe even source code online as a download or on a disc to be supplied is entirely feasible. But Intel decided against, leading me to think they really intended it to be a backdoor-ish sort of thing, and that makes me really sad.

[1] https://archive.org/details/bitsavers_ibmpcat150ferenceMar84...

[2] http://boingboing.net/2012/01/10/lockdown.html

[3] http://boingboing.net/2012/08/23/civilwar.html

> they really intended it to be a backdoor-ish sort of thing

Occam's razor says they really just sell a ton of CPUs to huge datacenters and wanted to solve the problem of having to have some tech go out and physically reset a machine when it misbehaves. If you've ever accidentally powered down a machine that's sitting in some lights-out facility in Northern Alabraska, this kind of technology is a godsend. Now I'm not saying I'd bet my hat that it's 100% secure, or that Intel couldn't be thumb-screwed by the feds to use it as a backdoor in some scenario, but it wasn't built from the ground up to be one.

I agree with you on this one. I just see it as in band lights out management.

No, Occam razor says that if all you you want to do is LOM, you put an embedded computer running Linux and ssh, connected only to to power and to the console, and nothing else, not a SPARC (?!?) core running proprietary code that does way, way more than just implement support for LOM, and which has access to all memory and CPU state.

It's not a SPARC, it's an ARC. It's a very different processor.

The earlier ME versions used an ARC. The later ones use a SPARC.

ARC not was a simplified SPARC for CPU architecture teaching ? I had to build it on VHDL on my first year.

Well I have no idea how ARC came into existence, but looking at the ISA, it has nothing in common with SPARC (I write SPARC compilers for a living, so I know the ISA pretty well).

I don't know the full story it was a spin-off of the work that Argonaut did for the SuperFX chip in Star Fox on the SNES -> https://en.wikipedia.org/wiki/ARC_%28processor%29

That's exactly my thoughts --- the lack of much official information about ME beyond the fact that it exists and can do some stuff is troubling, plus the information gleaned from reverse-engineering it shows a much-obfuscated design. If they had documented it clearly and perhaps even released source for the software, we wouldn't be having this discussion.

http://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf

SPARC and Java(!) are present in this system. It gives a whole new meaning to the "3 billion devices run Java" advert...

Pretty much. No engineer will decide to port Java to an embedded OS running on a foreign CPU when tasked with implementing a LOM system! The requirements are dictated by some other party. We don't know who the other party is, and we don't know what are the requirements. It's very normal to be skeptical of all this magic technology.

They even changed the CPU at some point. It used to be ARC, now it's SPARC. The LOM aspect of it didn't change. It worked just fine with ARC before. So why did it change?

There is no technical reason why implementing the LOM function is easier or better with one CPU compared with another. In fact, there's no technical reason why implementing anything is easier with one CPU or some other CPU. The new CPU seems even less power-efficient than their old one. The only reason why you'd want a particular CPU architecture is if you want to run some particular code for that particular CPU. And apparently running this secret code is so important, that it was worth the huge expense of porting all the other already-existing, already-working firmware they had before.

Completely agree with your sentiment. Just one small nit-pick: Intel doesn't use SPARC, but a much more obscure, less documented, and very proprietary ARC core [1, 2 & 3]. Ostensibly it was chosen due to having some excellent low-power modes.

[1] http://en.wikipedia.org/wiki/ARC_%28processor%29

[2] http://www.eetimes.com/document.asp?doc_id=1248611

[3] http://blog.invisiblethings.org/2015/10/27/x86_harmful.html

They used to use ARC, then they switched to SPARC: https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf

You're describing how most IPMI controllers are implemented. This sounds great and all, until you realize the vendors don't bother to keep things up to date, and run all sorts of extra shit so they have a bigger feature list.

If only IPMI worked this way!

Yes, they use Linux, but, as you say, they run a bunch of other crap that's old and buggy, and the implementation of the protocol itself is not stellar.

How many bugs were found in IPMI implementations vs. ssh over the last 5 years?

We don't need IPMI, we really only need ssh, and a console that allows setting things up (like Open Firmware on RISC machines).

We don't need a new protocol for remotely accessing our machines, when we can remotely export the plain old machine console securely.

Some vendors do work the way I described, at least for their RISC offerings, although, for example, the Oracle ILOM runs some Java web server crap by default. But at least you can turn it off and use pure ssh! No IPMI.

"Never attribute to malice that which can equally be explained by stupidity."

Intel is a large company, with lots of engineers, both hardware and software, managers, marketers and project managers. Some really stupid decisions will come out of simple scope creep and someones pet project suddenly becoming the next product.

Outside of evidence of actual malevolent intention, what you have here is easily a project gone really really weird.

> If you've ever accidentally powered down a machine, ... this kind of technology is a godsend.

How do I use this technology to, say, boot my turned off but plugged in and network-connected laptop?

I mean in a legitimate way. I'd really love to see how this works (and then be horrified).

Search Google for AMT tools. You will find what you are looking for. AMT will need to be turned on from the BIOS though

> If you've ever accidentally powered down a machine that's sitting in some lights-out facility in Northern Alabraska, this kind of technology is a godsend.

I don't get your point. If it's just about OOB management, then there are already plenty of BMC technologies out there (IPMI, ILO, ...). There is no need for AMT/ME here. Or maybe I just misunderstood how this whole thing works.

You can find IPMI on server-grade motherboards everywhere, yes. But what about thousands of laptops and PCs? That's the point of AMT - integrated with enterprise management system (like Tivoli) you can manage all the things you need on thousands of devices in your company. That's huge.

Reply on news.ycombinator.com