kernel 4.14 has intel mei_me module re-enabled

[mvermaes]

Qubes OS version:

R4.0

Affected component(s):

Kernel

---

Steps to reproduce the behavior:

lsmod | grep mei

Expected behavior:

No output from above command

Actual behavior:

mei_me and mei modules are loaded

General notes:

• These modules were removed from both 3.2 and 4.0 kernels in QubesOS/qubes-linux-kernel@e0f8e9c
• They were re-enabled in 4.0 as part of the cleanup in QubesOS/qubes-linux-kernel@537e0d1
• I'm not really sure how much is gained by disabling these modules anyway, but I couldn't see any reason for them to be disabled in 3.2 and enabled in 4.0

---

Related issues:

[lunarthegrey]

Same module is loaded for me. Running kernel 4.14.35-1.

[lunarthegrey]

Same module is loaded for me. Running kernel 4.14.35-1.

[lunarthegrey]

The mei and mei_me modules are still loaded with the 4.14.41-1 kernel (latest stable as of now). Is there any specific reason why the modules were added back @HW42 ?

[lunarthegrey]

The mei and mei_me modules are still loaded with the 4.14.41-1 kernel (latest stable as of now). Is there any specific reason why the modules were added back @HW42 ?

[lunarthegrey]

Still wondering why. Maybe @andrewdavidwong can help?

[lunarthegrey]

Still wondering why. Maybe @andrewdavidwong can help?

[andrewdavidwong]

Still wondering why. Maybe @andrewdavidwong can help?

I haven't the foggiest, but I bet @marmarek does.

[andrewdavidwong]

Still wondering why. Maybe @andrewdavidwong can help?

I haven't the foggiest, but I bet @marmarek does.

[marmarek]

The reason is simple and not very technical - we try to avoid maintaining custom kernel configuration as much as possible, as we don't have much resources for that (including testing configurations for new drivers etc). For this reason we reuse Fedora kernel configuration as a base.

Disabling mei_me module doesn't really disable ME. It only means that kernel wouldn't be able to ask nicely ME for some information (and the same user space daemons - but we don't have any for this device). ME will still be able to extract whatever information it want, because it has full access to system memory at CPU level, sadly.

Anyway, if you like to help to disable it, send a pull request to adjust custom options for the kernel. Please test it first.

[marmarek]

The reason is simple and not very technical - we try to avoid maintaining custom kernel configuration as much as possible, as we don't have much resources for that (including testing configurations for new drivers etc). For this reason we reuse Fedora kernel configuration as a base.

Disabling mei_me module doesn't really disable ME. It only means that kernel wouldn't be able to ask nicely ME for some information (and the same user space daemons - but we don't have any for this device). ME will still be able to extract whatever information it want, because it has full access to system memory at CPU level, sadly.

Anyway, if you like to help to disable it, send a pull request to adjust custom options for the kernel. Please test it first.

[lunarthegrey]

Thanks for explaining @marmarek. It's probably easier for us to just add mei, mei_me, and mei_wdt modules to the blacklist in /etc/modprobe.d/blacklist.conf and dracut -f to rebuild initramfs.

I know it doesn't disable ME, but preventing any type of communication between the kernel and ME may lower the attack surface (maybe?). It is dom0 after all, so if dom0 is compromised all hope is lost anyways.

[lunarthegrey]

Thanks for explaining @marmarek. It's probably easier for us to just add mei, mei_me, and mei_wdt modules to the blacklist in /etc/modprobe.d/blacklist.conf and dracut -f to rebuild initramfs.

I know it doesn't disable ME, but preventing any type of communication between the kernel and ME may lower the attack surface (maybe?). It is dom0 after all, so if dom0 is compromised all hope is lost anyways.