search

Nitrokey / heads

A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops and servers.
http://osresearch.net/
GNU General Public License v2.0
15 stars 1 forks source link

Intel Management Engine not actually disabled on NK Heads 2.4? #39

Closed UndeadDevel closed 9 months ago

UndeadDevel commented 9 months ago

Please identify some basic details to help process the report

A. Provide Hardware Details

1. What board are you using (see list of boards here)? NV41 2. Does your computer have a dGPU or is it iGPU-only?

3. Who installed Heads on this computer?

4. What PGP key is being used?

5. Are you using the PGP key to provide HOTP verification?

B. Identify how the board was flashed

1. Is this problem related to updating heads or flashing it for the first time?

2. If the problem is related to an update, how did you attempt to apply the update?

3. How was Heads initially flashed

4. Was the board flashed with a maximized or non-maximized/legacy rom?

5. If Heads was externally flashed, was IFD unlocked?

C. Identify the rom related to this bug report

1. Did you download or build the rom at issue in this bug report?

2. If you downloaded your rom, where did you get it from?

Please provide the release number or otherwise identify the rom downloaded 2.4 official release 3. If you built your rom, which repository:branch did you use?

4. What version of coreboot did you use in building?

5. In building the rom where did you get the blobs?

Please describe the problem

Describe the bug While digging into the cbmem logs (accessed from Heads recovery shell) to try to find more relevant data for fixing the battery charging limits problem (#35), without success, I did happen upon worrying data about Intel ME, which indicates that it is actually enabled, while I've been lead to believe that it would be disabled via HAP bit as before; what I've found now under NK Heads 2.4:

  1. in Heads RS viewing cbmem log, "Firmware Init Complete" says "YES" (supposed to say either "NO" or "Initializing")
  2. in Heads RS viewing cbmem log it says "ME is enabled."
  3. in QubesOS dom0 running sudo dmesg | grep mei returns: mei_me 0000:00:16.0: enabling device (0000 -> 0002)
  4. in QubesOS dom0 the ME device is visible under /dev/mei0

To Reproduce see above

Expected behavior "Firmware init complete" shouldn't say "YES" (as per me_cleaner docs and the original ptsecurity paper about HAP bit) cbmem log shouldn't say "ME is enabled." The ME shouldn't be visible from the OS and the OS shouldn't be reporting it as enabled.

Screenshots From NK Heads 2.4 cbmem log: Intel_ME_status_cbmem_Heads_2 4 Intel_ME_status_cbmem_Heads_2 4_2

Additional context I did do some checks on 2.1 about the ME status, which satisfied me, but I don't remember which tests I did.

daringer commented 9 months ago

uha, thanks for reporting, this indeed looks like a regressions - a first investigation shows that it might have something to do with how dasharo/coreboot handles variables which are expected to be set from EDK2 ... before 1.7.x dasharo it worked fine to just include a flash-descriptor with the HAP bit disabling ME - but now it looks like dasharo/coreboot overwrites this. we'll investigate this further, in the meantime I add it as a known bug to the release

UndeadDevel commented 9 months ago

Uh oh...well in my understanding both CPUs offered with the NV41 at least don't have vPro Enterprise, only vPro Essentials, so no AMT, which means no out-of-band wireless connectivity, at least if Intel is to be believed; but even "just" vPro Essentials is advertised as featuring "Intel Standard Manageability", which includes "Remote configuration".

That is to say, a hotfix for this issue would be very much appreciated.

As how likely do you assess the possibility of the ME communicating over a WiFi connection that the OS has established?

daringer commented 9 months ago

thanks again for reporting @UndeadDevel , fixed with https://github.com/Nitrokey/heads/releases/tag/v2.4.1 , closing