Ah, the smell of a billion dollar class action lawsuit in the morning!
An in-depth security review of the Intel Management Engine
151–160 of 192 posts
Re: An in-depth security review of the Intel Management Engine
#152Earlier quoted context omitted.
> I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there. > If they were more transparent, then they could be used by normal users for remote administration as well. The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes…
> The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious. Erm, your fundamental objection is exactly the same objection as it being non-libre. You presented the same argument while trying…
The source code won't give you shit. Even if you have it all, right here, right now:
1. you cannot disable it completely - there's an image of Intel ME, burned into the chipset, which checks for the presence of the ME + AMT in the SPI flash, and it checks for signature. (There's an exception to this, with skylake and above)
2. you cannot run a modified or reverse engineered version of it, unless you have Intel's private key to sign your own binary.
Basically the hardware is tivoized.
Re: An in-depth security review of the Intel Management Engine
#153Re: An in-depth security review of the Intel Management Engine
#154Earlier quoted context omitted.
> or if they allowed complete disabling via motherboard jumper That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) All the stuff that used to be done "manually" by the CPU itself back in the 8086 days—using configured IRQs and PITs and whatever else—is done autonom…
It's sad to me that manually setting an IRQ is so horrible a prospect that it's better to compromise the entire system. Honestly, I don't understand why there needs to be another CPU in the system. Do systems really need arbitrary bus protocol translation in real time? If people could agree to reasonable standards (a real possibility in the technological asymptote we have entered) we can eliminate this complexity ent…
> Honestly, I don't understand why there needs to be another CPU in the system.
There are tons of processors in modern systems. Most separate chips for controlling sub-systems have them, like DRAM, NICs, USB, keyboards, monitors, storage devices, video cards, etc...
The reasons are performance and flexibility - when separate components act like remote hosts, the device manufacturer can divide up work between the OS driver (main CPU) and target system as desired.
Re: An in-depth security review of the Intel Management Engine
#155Could someone explain what Management Engine is actually used for? It’s still not really clear to me why it needs to exist at all. Serious question.
Remote administration. Installing a new OS remotely, for example. There is legit demand for that. Imagine manually re-imaging 1000 workstations or servers.
That is AMT, which is just one application on the ME. More in general it aims to handle things the system should do independently of the OS, even when powered down.
That _can_ include advanced power management, secure computing stuff, watchdog functions and stuff like that.
Re: An in-depth security review of the Intel Management Engine
#156Unreal. Kept scrolling and the vulnerabilities kept coming. Most annoying thing is that there isn’t even a real alternative. If I understand it right then AMD chips have pretty much the same thing?
My alternative is a Librem: https://puri.sm/posts/purism-librem-laptops-completely-disab...
Note that the ME still runs on their platforms. They are not being honest about that fact.
Re: An in-depth security review of the Intel Management Engine
#157Earlier quoted context omitted.
> I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors They clearly invested some serious money into this sort of thing and see it as a differentiator (or AMD wouldn't have followed suit). Chances that they'll throw it all away because of a few vulnerabilities are very, very thin.
AMD has had their own version of this for quite some time. Its called the Platform Security Processor (PSP), it has been in anything AMD since around 2013 [0]. I am not sure if Ryzen / Threadripper has it, but I would be surprised if it didn't. [0] https://libreboot.org/faq.html#amd-platform-security-process...
If I'm not mistaken, PSP is not at all like ME, it runs code if you supply it with such but on it's own it doesn't listen to network traffic or run it's own OS, atleast, last I checked.
I'd still consider AMD the better player in the game.
Re: An in-depth security review of the Intel Management Engine
#158what i don't get is how would the consumer benefit of having these features? it all looks like a nonsense to me and I'd rather live without it. i think it's time to say goodbye to Intel and opt for another vendor.
That's the problem. There are no REAL alternatives.
Re: An in-depth security review of the Intel Management Engine
#159Wow all 6th, 7th and 8th gen are all vulnerable along with a bunch of Xeon processors. Even the laptop I am typing this on is vulnerable, this is going to be messy. Plus all the fun vulnerabilities like arbitrary code execution, unauthorized access to privileged content. These must be related to the blackhat talk coming up in December about hacking a turned-off computer and running unsigned code on ME [0]. Yep and th…
Please let this give rise to a class-action lawsuit. It's the only way this crap will stop.
Re: An in-depth security review of the Intel Management Engine
#160Earlier quoted context omitted.
i.MX6 is modern-ish and is bootable without blobs.
> i.MX6 is modern-ish and is bootable without blobs. i.MX8 will soon be released in quantity to the public and it is claimed by people who experimented with testing samples of it that it is similarly open as the i.MX6 in this sense.
As a quick note for folks who don't follow embedded SoCs: the NXP i.MX8 [1] is quite high-powered in this niche. It sports eight ARM cores in total: 4X Cortex-A53, 2X Cortex-A72, 2X Cortex-M4F.
As someone who has spent ~four years working on software for a single M4F, that reads like "it's a datacenter on a chip", more or less. It's ... big.
It also has dual-gigabit Ethernet, USB 3.0, USB 2.0, and enough other low/medium-speed serial interfaces to make you go dizzy. :)
I wonder what the pricing will be.
[1]: https://www.nxp.com/products/processors-and-microcontrollers...