Well, having a KVM that one can use to remotely connect to their machines is a good reason (if we leave the statement at this level and assume that everything is done in the best interests of the end-users, by their informed demand).
For example, having IPMI with serial console access or a full-fledged VNC on HP iLO on servers proved to be really useful on different occasions, where I was able to fix the boot-level problems remotely rather than having to drive for an hour to visit the server.
Remote access is of less importance with desktops - and even less with laptops - as in most cases user is physically present, but still I had a few cases where I regretted not having a way to remotely connect to my machine at home (it had failed after a power outage), while I was on the road.
I'd say, the very core idea isn't really bad. Intel's implementation is terrible.
If you want this there is no reason the software needs to be embedded in the hardware. Install a hypervisor with remote access, install the other OS in a VM and you have all the same capabilities through the hypervisor, but now you can inspect or improve the hypervisor and update it when it's vulnerable.
The whole point of a independent hardware KVM is that it's autonomous - no matter which state the software (and unrelated hardware) is in, you can still access the system and try to recover.
But, sure, I fully agree about the need of such system being an open platform that user can audit, update and control - rather than a black box. (Well, if there is a platform at all - a simplest external IP KVM could be a very dumb hardware box with the only software being an extremely primitive TCP/IP stack.)
Added: Anecdote: In early 2000s, some company I know of, had quite simplest remote access tools - DIY remote reboot devices made of externally-powered Realtek network cards. Sending a WoL packet to a known MAC (on a well-isolated network) would forcibly power-cycle the connected machine or router. No amount of fancy software solutions would bring a well-hung host back online. ;)
> The whole point of a independent hardware KVM is that it's autonomous
Which Intel ME isn't any more than a hypervisor is. It uses the same CPU and network interface and can be misconfigured in the same ways a hypervisor can. It essentially is a hypervisor but one that you can't remove or replace.
There are advantages to really independent hardware but firmware doesn't get you those, and there are advantages to management software but none of them require the software to be burned into the silicon. I agree that the feature set can be useful, it just doesn't belong where they put it (and in that sense we may only be arguing past each other).
There's no hypervisor that'll let you power up a halted server, change bios settings, change boot device or order, boot the system of pxe, etc, etc. It's not the same thing at all, and almost every server made in the last decade has a BMC that gives you all the remote access features anyways, so getting IME isn't much of a change there.
> There's no hypervisor that'll let you power up a halted server, change bios settings, change boot device or order, boot the system of pxe, etc, etc.
Wake on LAN is a 20th century technology that requires no other privileges to implement and can be access controlled via managed switches. Pretty much every hypervisor will allow you to turn on a VM, change its boot device order or boot PXE and can change BIOS/firmware settings on any platform with an API to do that.
Comparing Wake on LAN to a BMC is like comparing a text editor to an IDE. Most platforms don't have a way to change BIOS or firmware settings, and if they do, it's via the BMC anyways.
Yes, but BMCs do more than just power machines on and off, and are used for more than powering machines on and off. Automatic hardware provisioning fully depends on BMCs.
Intel is the party in control, and Dell, and Supermicro, and HP, and....
IPMI is the API you're looking for, you can always just shut off the networking. But again, it's still done through the BMC. SOMETHING has to do it, and that something needs access independent of the OS and the rest of the system due to the nature of the settings you can change.
Also how is IME any different than providing an API? The api has to actually do something, how exactly do you propose to do that without something like IME?
> Yes, but BMCs do more than just power machines on and off, and are used for more than powering machines on and off.
Turning on a powered-off machine is the only thing that couldn't be done by a hypervisor.
Once the machine is turned on, a hypervisor should be able to do anything IME does by doing it the same way IME does it, as long as the hardware is sufficiently documented.
The part of IME that is unnecessary is the software, because it's software in lieu of transparency and documentation. A separate management processor that you could install your own software on would not be a problem, and then you could even turn on the machine.
A hypervisor isn't going to be able to interact with Option ROMs, change C states, change the CPU's vt-x/vt-d parameters, configure the HBA, change device addressing, configure port signaling speed, etc.
That could all be implemented, but it would require another hardware controller or some sort of api that has lower level hardware access than the OS does, and something to actually provide that access and communicate with the various components, at which point you just invented IME/BMCs.
Edit:
>The part of IME that is unnecessary is the software, because it's software in lieu of transparency and documentation. A separate management processor that you could install your own software on would not be a problem, and then you could even turn on the machine.
I suppose I can agree with that, and that's basically what most BMCs are, though installing your own software is hit or miss. (I've read about someone that got a stripped down linux kernel+userspace running directly on a SM BMC once) , Intel just moved it into the cpu.
IME just seems like a strange hill to die on when it's probably more secure than 90% of the remote management setups in use today, yet everyone seems perfectly ok with those.
> That could all be implemented, but it would require another hardware controller or some sort of api that has lower level hardware access than the OS does, and something to actually provide that access and communicate with the various components, at which point you just invented IME/BMCs.
What you've really invented is hardware drivers, which have been at home in the OS forever.
> IME just seems like a strange hill to die on when it's probably more secure than 90% of the remote management setups in use today.
The problem is they put it everywhere instead of only where people asked for it. You can get away with more on something which is opt in because the people who don't like it can get the one without it. So now it doesn't have to be as secure as the other remote management setups, it has to be as secure as not having remote management.
>What you've really invented is hardware drivers, which have been at home in the OS forever.
Those drivers need to actually communicate with something though, that something is exactly what BMCs are. If the hardware physically providing communication with those systems isn't there, no amount of drivers will help. Additionally, many of those things have to be configured before the OS is loaded and the hardware they control is fully initialized. Not possible inside the OS.
>The problem is they put it everywhere instead of only where people asked for it. You can get away with more on something which is opt in because the people who don't like it can get the one without it. So now it doesn't have to be as secure as the other remote management setups, it has to be as secure as not having remote management.
Yeah, I guess that's an aspect I didn't think of. I can see why people wouldn't be happy running remote management on their consumer hardware, I guess my view is biased by the fact that on systems I frequently work with, having a BMC is a given. My only experience with IME in consumer-level hardware was a neutered version of it where remote access wasn't an option, just some local hardware monitoring/management that seemed mostly useless, but I guess that must've changed.
> Those drivers need to actually communicate with something though, that something is exactly what BMCs are. If the hardware physically providing communication with those systems isn't there, no amount of drivers will help. Additionally, many of those things have to be configured before the OS is loaded and the hardware they control is fully initialized. Not possible inside the OS.
You're going to have a chicken and egg situation at boot. The SATA/SAS HBA needs some code to read the OS with, but in a sense this is just a piece of your OS that has to be installed on the HBA, in the same way as grub has to be installed in the boot partition. Once the OS is running it can load different code into the HBA or replace the code that will run on the next boot.
We can argue about whether to call that sort of code a BMC or not but the more important question is if people can replace it or not, so that people can fix things the manufacturer doesn't.
For example, having IPMI with serial console access or a full-fledged VNC on HP iLO on servers proved to be really useful on different occasions, where I was able to fix the boot-level problems remotely rather than having to drive for an hour to visit the server.
Remote access is of less importance with desktops - and even less with laptops - as in most cases user is physically present, but still I had a few cases where I regretted not having a way to remotely connect to my machine at home (it had failed after a power outage), while I was on the road.
I'd say, the very core idea isn't really bad. Intel's implementation is terrible.