The ME is purportedly placed in "recovery" mode:
According to Nicola Corna, the current ME state should have been changed from “normal” to “recovery”.
I don't speak for the FSF, but it sounds like this is as close to an FSF RYF certification as any Intel CPU is going to get. FSF approval of a device requires that all user-modifiable software be Free Software. Previously, no recent Intel CPUs could be FSF certified as "RYF" because the ME chip would shut the system down after 30 minutes. (Side note: no recent Intel CPUs can be considered "stable" without microcode updates which also violate the FSF's RYF guidelines.)
EC/SMC are highly board specific, some even run open source firmware that can be replaced (eg. on Chromebooks)
The issue with the ME is that its firmware is signed with an internal Intel key, combined with its property of having full access to the entire system.
Even with this hack of invalidating most of the firmware, we don't know for sure what is left running on the ME.
The EC, SMC, and other blobs are much more the domain of the board designer, and are much easier to make a libre implementation for.
No, it does not. FSP only includes x86 code to be executed on the main CPU. It may include stuff which talks to the ME but no ME firmware itself. You can use any UEFI extractor like UEFITool to check that.
# shutdown -r now
# echo b > /proc/sysrq-trigger
edit: there was a star but HN formatting ate it
That's not possible, but the next best thing is to have it never activate unless major changes are made to the BIOS flash, and those changes should be very visible.
Your computer suddenly reboots: very visible.
The flash partition table and/or BIOS suddenly change: very visible.
flashrom -p internal -r bios.rom
ifdtool -x bios.rom
python3 me_cleaner.py flashregion_2_intel_me.bin
python2 dump_me.py flashregion_2_intel_me.bin -x
python2 me_sigcheck.py FTPR_part.bin
ifdtool -i ME:flashregion_2_intel_me.bin bios.rom
exit # Skip this line if you're okay with bricking your motherboard.
flashrom -p internal -w bios.rom.new
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : NO
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: Current Working State : Initializing
ME: Current Operation State : Bring up
ME: Current Operation Mode : Normal
ME: Error Code : Debug Failure
ME: Progress Phase : BUP Phase
ME: Power Management Event : Pseudo-global reset
ME: Progress Phase State : 0x3b
ME has a broken implementation on your board with this BIOS
ME: failed to become ready
* A set of software tools: Check
* Unauthorized user: Check Caveat: user is not authorized by you, but by someone else (Intel)
* Gain control of a computer system without being detected. Can access your machine while it appears to be "powered off" but plugged in. Has full access to RAM. Can draw undetected on top of screen. Can read screen. Check.
So. Does this qualify the Management Engine as a rootkit? It meets the definition. Just because the rootkit is installed by the manufacturer doesn't make it less of one.
It's also conceivable that a state-level adversary could have hidden arbitrary DMA instructions in a NIC firmware, that only activate with a signed request embedded in a random packet. Some of the largest firmware blobs on Linux systems are for NICs.
Most people aren't facing state-level targeted attacks, but without open firmware, it's nearly impossible to know for sure if one is vulnerable. And, with botnets and worms, it only takes one non-state-level attacker discovering the backdoor for everyone to be affected.
PDF Page 66
This attack could be used indefinite times to compromise the Intel’s AMT remote provisioning process and subverts the security of the non configured PCs that include the AMT functionality even while it is disabled within the BIOS configuration as presented in section 3.7.6.
AMT is always active, even if you've set it to "Disabled" and can be remotely activated. Again, without your authorization.
RISC-V can't take the market over fast enough.
There's the Talos Secure Workstation, which has no such ME firmware (but costs ~$4.5k) .
A RISC-V desktop is pretty far out. There is an Arduino style microcontroller being made in silicon, though .
Source: MeetBSDCon 2016, update on RISC-V by the team who designed it.
Wrong question. Correct question would be: "How much are you willing and able to pay for it?" (for me it much more strongly fails because of the second criterion).
Just for example, you are using OpenBSD and full disk encryption and you think you are safe? What if the firmware on your NIC can be altered to scan your RAM (using DMA) and send the interesting data (big prime numbers, passwords, etc.) home? What if firmware on your keyboard can be modified (or pre-programmed in factory) to record the last x thousands of keypresses (which will include your boot disk password) on its own flash memory which can be later extracted? There are so many attack vectors.
Will the RISC-V based CPU in your computer be Open Source?
A parallel example is while WebKit is Open Source Chrome isn't
Of course there will be both proprietary and open implementations of RISC-V.
Unlike software, you can't just download the code, you have to pay for a fab
Surely, at least 1 Intel staffer reads HN and they must have discussed this internally.
Unless they just brush this off as negligible (a couple thousand paranoid/"extremist" users) ?
Anyone who works there, has access to the required information, and is unhappy at the situation surrounding ME and other freedom-hostile directions your company is taking, you know what to do!
How hard is it to imagine some special string in RAM could trigger the ME in a similar way? (so many CPU instructions - I would be surprised if there wasn't one to talk to the ME)
Exploits and vulnerability are mitigated by proper analysis and ecological diversity.
Here we have an attack channel present of every single Intel based computer, regardless of the CPU.
Call me an extremist if you want, but this is far from harmless.
Asking for a project.
The ME is very alarming, and seems to only become more alarming the closer you look at what it is designed to do.
+1 for the use of ifdtool.
VIA is 100% a viable option—they support SSE 4.1, run Windows 10, and their integrated GPUs even run DirectX11 natively¹—except that they compete with Atom, not desktop or even regular laptop CPUs. However, the current (40nm Isaiah) “high-end” VIA microarchitecture is a out-of-order, 3-fetch 7-dispatch wide² superscalar, fully pipelined core. So it should outperform a modern Atom by a decent margin, with only slightly higher power consumption.
Apparently VIA is still fairly popular in China (and by virtue of being a Taiwanese company, possibly Japan as well).
1. See e.g. http://www.viatech.com/en/boards/mini-itx/epia-m920/
"With ME neutralized, the MEI interface disappears from the PCI bus, and the integrated NIC ceases to work, but will resume to work after a reboot."
Why would the NIC only break once after the ME is neutralized? The system is started from a fully powered-off state after the ME firmware is updated. Maybe the NIC has some sort of non-volatile state that gets updated when the ME fails to initialize, and then the NIC starts working again. That's the most complex explanation so I thought it unlikely, but I'm happy to hear more from someone who has actually neutralized their ME.
After a reboot, the NIC starts without the ME ever taking control of it, so it works.
It's not strictly clear to me, but reading through what they're doing, the ME isn't re-engaged or its unclear how it recovers itself.
Unless the ME is operating with a recovery binary somewhere that isn't covered by Nicola's neutralizer and the subsequent flashing, I don't think it comes back in to normal operation.