Hi Sandy,
On Thu, Sep 7, 2017 at 2:37 AM, Sandy Harris sandyinchina@gmail.com wrote:
Recently a few things have been revealed about how to disable the Intel Management Engine (ME).
http://blog.ptsecurity.com/2017/08/disabling-intel-me.html https://www.theregister.co.uk/2017/08/29/intel_management_engine_can_be_disa...
I have not seen anything on disabling the similar AMD feature called PSP. Either appears to be a huge security hazard -- a device you have little choice but to trust but that you have little control over, that operates below the level of the main CPU & OS, that has access to everything & that is Turing complete so it can do anything.
There's not much public research about AMD PSP yet. From the SW/FW/HW's perspective, a hardened kernel is still important( that's why PaX/Grsecurity matters a lot) to prevent some attack surfaces from lower level( let's say Hypervisor( RING -1)/SMM( RING -2/ME( RING -3)). But the lower level should be concerned as well. We've been pushing this solution into our customer's production and it's looking good so far:
https://github.com/hardenedlinux/hardenedlinux_profiles/blob/master/slide/ha...
By the time a hardened kernel loads, it may be too late to prevent ME entirely, but are there other things the kernel could do? Issue a syslog warning? Monitor ME activity somehow? Restrict its access to the network so at least external attacks are blocked?
Intel ME has a OS kernel( ThreatdX/MINIX-based) running on a specific CPU( < v11 is ARC, >=v12 is x86). There's not much kernel can do about it except a few LKMs( mei/mei_me) can getting some info from the ME.
There are several different utilities to reduce ME danger, though I have not looked at details & I have the impression most do not disable it completely. Will current hardened kernels run on a system with ME disabled? Is that tested?
There are two ways to "disable" ME:
1) Before Mark Ermolov and Maxim Goryachy disclosured this HAP "secrects" to the public, what me_cleaner( https://github.com/corna/me_cleaner/) does was removing more ME code modules as possible and only keep those necessary ones( like BUP/ROMP/etc). It's not 100% disable it but neutralization achieve the similar goal. me_cleaner is a free/libre software, all you need to prepare is a few cheap hardwares( external programmer):
https://hardenedlinux.github.io/firmware/2016/11/17/neutralize_ME_firmware_o...
2) Thanks to Mark Ermolov and Maxim Goryachy, now me_cleaner added an option( -s) can enabled the HAP bit but keep other code modules as well. Plz note that some private OEM firmware implementation might have some side-effects while coreboot is working perfectly( less SMIs helps?) so far. There are some public test results you can find:
https://github.com/hardenedlinux/hardenedlinux_profiles/tree/master/coreboot https://github.com/corna/me_cleaner/issues/53
The best summary of the issue I have seen -- though it is neither up-to-date nor devoted to only the one issue is: https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
There has been discussion on the Qubes users list: https://groups.google.com/forum/#!forum/qubes-users
More fw/ME info:
https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/me_inf... https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/firmwa...
The only plausible solutions suggested there boil down to not using recent x86 chips at all. Either use older Intel/AMD parts without the feature or go to IBM Power CPUs.
IMOHO, RISC-V will be the long-term solution in the future;-)
btw: this might a little bit off-topic on kernel-hardening( I could be wrong if it weren't). Or feel free to ask question on coreboot's mailinglist: coreboot@coreboot.org
-
Shawn