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