Scary, I did not know this
I'm sure Intel has a real good reason for it being there but I would feel much more comfortable with it either not being there or being able to disable it in hardware.
I'm sure Intel has a real good reason for it being there but I would feel much more comfortable with it either not being there or being able to disable it in hardware.
Doubt that will change anything (willingness, price for probably new masks etc. etc.) but it would certainly be nice.
Intel needs to give us an alternative.
The ideal security mechanism would provide us with a per cpu key from Intel, which we use to update our own user key to the cpu, and only user signed firmware is loaded.
The exact mechanism of this can be handled in many ways.
Right now, we locked out, and primed for being snooped on without our consent.
I like Intel's engineering, but everything else I could do without.
And ARM is no better. I'd say worse actually, but I'm not going to defend that.
Please, please, AMD do the "right thing" with Zen. Allow us to be in command of our security, so we may delegate it to those we trust with the technical know how, be it OS vendors, or our IT departments, or our own selves.
Heck, just access the HD where you boot your OS from and reimage it.
--
¹ https://libreboot.org/faq/#intelme See paragraph 6.
² https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J
³ http://www.eteknix.com/expert-says-nsa-have-backdoors-built-...
⁴ http://www.infowars.com/intel-ceo-refuses-to-answer-question... (Note the NSA slide.)
⁵ https://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_b... (No hard evidence, but he dodged basically every question related to the NSA.)
Better citation needed. AFAIK the ME has never been used for DRM. It's supposedly used to implement TPM 2.0 aka PTT, but AFAIK that has never been used for DRM either.
https://www.slideshare.net/mobile/codeblue_jp/igor-skochinsk...
AFAICT Intel's desktop RAID tech literally just remaps PCI vendor and device ids (which is a wee bit more complicated with NVMe / AHCI over SATA Express). The boot process was an option ROM and is presumably now baked into UEFI. The driver does the rest.
I can imagine that a couple bits in ME tell the UEFI blob and the driver which feature set to enable. Is there more?
One of many implementations: http://www.upsidedowntext.com/
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.
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. ;)
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).
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.
That's the point. If all you need is the ability to power on the machine, why are you exposing any more than that to the network?
> Most platforms don't have a way to change BIOS or firmware settings, and if they do, it's via the BMC anyways.
And the party in control of that is Intel, so they could provide that API instead of IME.
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?
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.
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.
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.
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.
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.