no longer disable Intel ME related kernel modules

[adrelanos]

For rationale, see:
https://www.kicksecure.com/wiki/Out-of-band_Management_Technology#Intel_ME_Disabling_Disadvantages

## Intel Management Engine (ME):
## Partially disable the Intel ME interface with the OS.
## ME functionality has increasing become more intertwined with basic system operation.
## Disabling may lead to breakages places such as security, power management, display, and DRM.
##
## https://www.kernel.org/doc/html/latest/driver-api/mei/mei.html
## https://en.wikipedia.org/wiki/Intel_Management_Engine#Security_vulnerabilities
## https://www.kicksecure.com/wiki/Out-of-band_Management_Technology#Intel_ME_Disabling_Disadvantages
## https://github.com/Kicksecure/security-misc/pull/236#issuecomment-2229092813
##
install mei /usr/bin/disabled-intelme-by-security-misc
install mei-gsc /usr/bin/disabled-intelme-by-security-misc
install mei_gsc_proxy /usr/bin/disabled-intelme-by-security-misc
install mei_hdcp /usr/bin/disabled-intelme-by-security-misc
install mei-me /usr/bin/disabled-intelme-by-security-misc
install mei_phy /usr/bin/disabled-intelme-by-security-misc
install mei_pxp /usr/bin/disabled-intelme-by-security-misc
install mei-txe /usr/bin/disabled-intelme-by-security-misc
install mei-vsc /usr/bin/disabled-intelme-by-security-misc
install mei-vsc-hw /usr/bin/disabled-intelme-by-security-misc
install mei_wdt /usr/bin/disabled-intelme-by-security-misc
install microread_mei /usr/bin/disabled-intelme-by-security-misc

Disabling Linux Intel ME related kernel modules does nothing to disable Intel ME from the CPU.

related:

• Disable more Intel ME kernel modules #236
• Disable some Intel PMT kernel modules #237
• criteria for kernel module blacklisting / disabling / Suggestions for kernel modules blacklisted in /etc/modprobe.d/30_security-misc.conf #224

[raja-grewal]

In my opinion, I think the Intel ME kernel module components should be disabled by default for all Kicksecure/Whonix installations.

Personally I think the user base of Kicksecure/Whonix would prefer to have all these kernel modules disabled by default.

While disabling has no impact on internal CPU components, they exist to provide a convenient interface with the OS and this should be optional.

One thing we could do is provide very clear information regarding the downsides of having them disabled relating to security, power management, display, and DRM (as shown in the wiki).

Perhaps move the disabling of ME kernel modules in their own separate file in /etc/modprobe./ so they are easy for someone to re-enable?

While we do not have any telemetry, users of non-Intel systems would be in favour of continued disabling.

While Intel CPU users might have a diminished experience regarding battery life, whoever, if we were to provide clear documentation and information allowing the user to make an informed choice I think would be good.

Overall, I don't think shipping a new Kicksecure/Whonix version with the kernel modules no longer disabled without first receiving some community feedback is something I would recommend. Which I suppose is the purpose of this post.

TL;DR; consider reverting 6157e32.

https://forums.whonix.org/t/kernel-hardening-security-misc/7296/559

[adrelanos]

The issues with disabling Intel ME related kernel modules by default:

• Not clear what these many kernel modules even do.
• No threat model yet.
• Can cause issues.

What's the threat model?

Remote code execution? Can these kernel modules aid a remote attacker?

Local privilege escalation? Can these kernel modules help a limited user account (such as let's suppose there is a web server running under user www) to escalate to root?

Personally I think the user base of Kicksecure/Whonix would prefer to have all these kernel modules disabled by default.

While we do not have any telemetry, users of non-Intel systems would be in favour of continued disabling.

I am sure, without knowing any technical details it seems a good idea to use a big hammer and throw it on anything even remotely related to Intel ME, because we don't like a complete, non-freedom software running inside our CPU. Even if this change does nothing about the Intel ME running inside the CPU.

So for popularity reasons, it surely seems a good idea.

But if any issues are caused such as maybe...

• Just speculating on what kind of issues might happen if we mess with things we don't understand...
• Overheating CPU.
• Lower battery life.
• Crashes.
• Broken firmware upgrades (through fwupd?)
• Power management, such as dim keyboard, screen.
• Suspend to RAM.
• Suspend to disk.
• DRM.
• Multiple displays.
• TPM.

...then these requests will vanish and it will suddenly seem like a bad idea.

How do we even know? This could use some more attention from the security community, not just security-misc.

Is it a valid approach to look up what kind of issues people experienced that disabled / neutered (part of) Intel ME? That will be related to the Intel ME running inside the CPU, not related to the kernel modules. Not sure how well that compares.

One thing we could do is provide very clear information regarding the downsides of having them disabled relating to security, power management, display, and DRM (as shown in the wiki).

Yes. And if it is decided to disable Intel ME related kernel modules by default, then Kicksecure should probably have a wiki page https://www.kicksecure.com/wiki/battery that users can easily discover. Should someone suspect battery issues, they could try re-enable the Intel ME related kernel modules by simply deleting that configuration file.

Perhaps move the disabling of ME kernel modules in their own separate file in /etc/modprobe./ so they are easy for someone to re-enable?

Sure. That seems useful irrespective of whether this becomes a default or not.

Next useful steps:

• Post feature requests against other security-focused projects to suggest to do the same. This is to get more input, expert opinions.
• Find, share, read all available documentation on these kernel modules.
• Find, read the source code of these kernel modules.

[adrelanos]

I've looked up the documentation for all kernel modules. Doesn't seem any thing crucial. Keeping notes here:
https://www.kicksecure.com/wiki/Out-of-band_Management_Technology#Intel_ME_Kernel_Modules

[adrelanos]

Reverted. Now back to disabling Intel ME related kernel modules. After looking more what these modules do, it does not seem to be related to the issues that I expected.

[adrelanos]

Actually, now on yet another look... Considering to revert the revert, i.e. keeping Intel ME related kernel modules enabled.

Firmware updates:

About mei-gsc kernel module...

Quote https://cateee.net/lkddb/web-lkddb/INTEL_MEI_GSC.html

An MEI device here called GSC can be embedded in an Intel graphics devices, to support a range of chassis tasks such as graphics card firmware update and security tasks.

So we could break firmware updates, which might be security critical. This seems like a strong reason to keep Intel ME related kernel modules enabled by default?

Also I don't think we should just disable only some Intel ME related kernel modules but keep this one enabled by default? This is because we don't know (and realistically cannot maintain, keep following-up on this) the interaction / dependency chain for these modules.

DRM:

Disabling all Intel ME related kernel modules might also break DRM but that we could take and document in the wiki on how to undo re-enabling Intel ME (if it will be disabled by default). So if it was only about DRM, I would say accept the usability degradation and keep Intel ME disabled.

[adrelanos]

• Intel graphic card firmware updates broken due to Intel ME kernel modules disabling in Qubes QubesOS/qubes-issues#9369

[adrelanos]

https://github.com/QubesOS/qubes-linux-kernel/blob/main/config-base

CONFIG_INTEL_MEI=m
CONFIG_INTEL_MEI_ME=m
CONFIG_INTEL_MEI_TXE=m
CONFIG_INTEL_MEI_GSC=m
# CONFIG_INTEL_MEI_VSC_HW is not set
CONFIG_INTEL_MEI_HDCP=m
CONFIG_INTEL_MEI_PXP=m
CONFIG_INTEL_MEI_GSC_PROXY=m

[raja-grewal]

Yes it seems that the majority of projects do not meddle at all with the ME kernel modules. This is certainly a good idea in terms of preventing any potential breakages as outlined above.

Our current approach of just blocking them without any significantly substantiated is definitely quite extreme. I would argue we do so from an abundance of caution and to "reduce attack surface" at the cost of not really knowing with certainty what our disabling is very specifically impacting.

Next useful steps:

• Post feature requests against other security-focused projects to suggest to do the same. This is to get more input, expert opinions.
• Find, share, read all available documentation on these kernel modules.
• Find, read the source code of these kernel modules.

As suggested, if we still want to continue (blindly?) disabling these modules, we should continue with this approach of researching and discussion.

The only other path that I can currently think of is resource-intensive. It would be to get some sort of empirical data across a wide spectrum of Intel CPUs and run tests/benchmarks to actually obtain an evidence-backed argument. While this would be a truly novel experiment, I imagine this is outside the scope of this project (for now).

[adrelanos]

I would argue we do so from an abundance of caution and to "reduce attack surface" at the cost of not really knowing with certainty what our disabling is very specifically impacting.

In this case, there's not even a consensus recommendation of doing so, but a strong indication of even reducing security, namely breaking firmware updates.

Abundance of caution can't really be a suitable criteria because there a hundreds or thousands of kernel modules. That's too big in scope for a a security "miscellaneous" project. That would best maintained by a separate project. (#224)

While this would be a truly novel experiment, I imagine this is outside the scope of this project (for now).

Indeed.

[adrelanos]

Now implemented no longer disable Intel ME related kernel modules for the purpose of not breaking firmware updates.