Intel CPU Management Engine
With all the noise about the Intel CPU Management Engine (ME) SA-00086 flaws, I downloaded the Linux detection tool. The Windows folks get a nice little GUI app. The Linux folks get a tar.gz containing some Python scripts.
The scripts are, well, anemic and possibly useless.
On all Intel systems I blacklist the mei and mei-me modules. Doesn't hurt to be cautious and a tad paranoid. Keep the tin foil hats handy.
The intel_sa00086.pyscript bails because the mei and mei-me modules are not loaded. The output spew provides a vague clue to load the modules, although the output spew references installing the MEI/TXEI driver. This is a Linux system. The reminder should have asked users to load the appropriate modules. Technically the same, but shows the Windows influence and thinking.
I ran the Python script on my HP dc7900 running Ubuntu MATE 16.04 64-bit. I saw an uninformative message that my system may be vulnerable. That’s all. Truly, truly helpful.
I saw the same “helpful” message on my Thinkpad T400 running Slackware 14.2 64-bit. Except this time I experienced a Python traceback.
Traceback (most recent call last):
File ."/intel_sa00086.py", line 133, in <module>
sys.exit(main())
File ."/intel_sa00086.py", line 75, in main
ver_str, code, family, svn = get_fw_state()
File "/tmp/SA000086/heci.py", line 91, in get_fw_state
fw_ver = get_fw_ver()
File "/tmp/SA000086/heci.py", line 70, in get_fw_ver
mei_fd = get_mkhi_fd()
File "/tmp/SA000086/heci.py", line 29, in get_mkhi_fd
fixed_address_soft(dev_node, True)
File "/tmp/SA000086/mei/debugfs.py", line 88, in fixed_address_soft
if get_fa_support(device):
File "/tmp/SA000086/mei/debugfs.py", line 121, in get_fa_support
_, hbm = get_devstate(device)
File "/tmp/SA000086/mei/debugfs.py", line 98, in get_devstate
mei_dir = check_for_debugfs(device)
File "/tmp/SA000086/mei/debugfs.py", line 69, in check_for_debugfs
if not valid_path(mei_dir + ‘/meclients’):
TypeError: unsupported operand type(s) for +: ‘NoneType’ and ’str'
I am not a Python programmer, but looks like some variable type declarations are incorrect. Again, truly, truly helpful. Did anybody actually test these scripts?
A system with an i5-6400 Skylake is “considered vulnerable.”
A system with a Celeron 1037U is not vulnerable.
I downloaded the mei-amt-check program. For that program to work I again had to load the mei and mei-me modules. At least the output spew of this test program informed the user to modprobe mei_me.
On the HP dc7900 I was informed that Intel AMT is present and AMT is being provisioned. The test script offers no help at what being means and there is no other output. The system BIOS reports an ME firmware version of 5.0.3.1126. I was able to configure the BIOS to show the ME boot prompt (Ctrl+P). After accessing the ME I was required to change the password from the default admin. The new password has several anal restrictions. I then was able to “unprovision” the configuration. The mei-amt-check program then reported the same results.
On the T400 I was informed the Intel AMT is present but AMT is unprovisioned. In the system BIOS I have AMT disabled. Enabling AMT revealed version 4.0.8.1139 and the same Ctrl+P prompt when booting the system. The ME interface looked the same as the HP dc7900. Running the two scripts after enabling AMT had the same results.
On the i5-6400 Skylake I was informed that Error: Management Engine refused connection. This probably means you don't have AMT. Likewise for the Celeron 1037U.
Curious though is these test scripts fail to query the CPU ME unless the modules are loaded.
Posted: Category: Usability Tagged: General
Next: Server Crash
Previous: Booting From USB