Intel Management Engine not actually disabled on NK Heads 2.4?

[UndeadDevel]

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?

• dGPU
• iGPU-only

3. Who installed Heads on this computer?

• Insurgo
• Nitrokey (originally)
• Purism
• Other provider
• Self-installed (internal upgrade to NK Heads 2.4)

4. What PGP key is being used?

• Librem Key
• Nitrokey Pro 2
• Nitrokey Storage
• Yubikey
• Other (NitroKey 3A Mini)

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

• Yes
• No
• I don't know

B. Identify how the board was flashed

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

• First-time flash
• Updating heads (update itself was successful, but a few regressions occurred, including this one)

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

• Using the Heads GUI
• Flashrom via the Recovery Shell
• External flashing

3. How was Heads initially flashed

• External flashing (by NitroKey)
• Internal-only / 1vyrain
• Don't know

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

• Maximized (presumably)
• Non-maximized / legacy
• I don't know

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

• Yes (presumably)
• No
• Don't know

C. Identify the rom related to this bug report

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

• I downloaded it
• I built it

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

• Heads CircleCi
• Purism
• Nitrokey (GitHub)
• Somewhere else (please identify)

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?

• Heads:Master
• Other (please identify)

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

• 4.8.1 (current default in heads:master)
• 4.13
• 4.14
• 4.15
• Other (please specify)
• I don't know

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

• No blobs required
• Provided by the company that installed Heads on the device
• Extracted from a backup rom taken from this device
• Extracted from another backup rom taken from another device (please identify the board model)
• Extracted from the online bios using the automated tools provided in Heads
• I don't know

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:

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]

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]

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]

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