Refresh /etc/modprobe.d/* blacklisting and disabling

[raja-grewal]

This pull request updates our list of blacklisted and disabled kernel modules.

The last major updates were done by us around July 2024 in #230, #232, #234, #236, #237, #238, and #245. There were also numerous updates by others not using the GitHub PR system and so harder to link.

This current refresh updates documentation, relocates a few things under better headings, moves some modules from blacklisted to disabled, and adds more disabled modules.

The biggest change is incorporating more disabled file systems form secureblue's config. These have all been used for a lengthy period sometime and so should be considered free of any obvious breakages.

Changes

Primarily disables more uncommon and legacy file systems.

Mandatory Checklist

• Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements:

Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

Optional Checklist

The following items are optional but might be requested in certain cases.

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

[ArrayBolt3]

Some things that could use discussion:

• I don't think we should consider the disabling of intel_rapl_msr part of the MSR disablement. intel_rapl_msr is AFAICT just a driver for RAPL that happens to use MSRs under the hood instead of TPMI. It doesn't actually expose those MSRs to the end user. We might still want to disable this module though, as RAPL's exposure of detailed power information can be used in side-channel attacks (one of which was known by Intel for four years before publication, see https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/running-average-power-limit-energy-reporting.html).
• isst_if_mbox_msr also looks like something that just uses MSRs under the hood but probably doesn't expose MSR write functionality directly. I'm not sure if we want to disable this one either.

Some things that need fixed before or after merge:

• Most of the blacklisted filesystems make sense to me, but 9p cannot be blacklisted, as it's needed for KVM shared folders to work in Whonix (at least with the current documentation for how to set up shared folders). See https://www.whonix.org/wiki/KVM#Shared_Folder
• The new script disabled-cpumsr-by-security-misc needs to be explicitly listed in debian/security-misc-shared.install due to the new split package architecture.

[raja-grewal]

Thank you for the review.

Regarding MSRs, I should have updated the description to be more explicitly encompassing of other reasons to disable these modules on top of the ability to write to memory. These includes:

• intel_rapl_msr which provides support for Intel's Running Average Power Limit (RAPL) technology via MSRs. It allows monitoring and enforcing power limits on modern Intel processors starting from Sandy Bridge.
• isst_if_mbox_msr provides an interface for Intel Speed Select Technology (SST) using MSRs. It allows user-space applications to communicate with the hardware to enumerate and control Intel Speed Select features, which are available on specific Intel Xeon server processors.

The Intel documentation you provided also gives an excellent reasoning for their blocking.

As a general rule, the attack scenarios from malicious unprivileged applications to other trust domains can be blocked by removing user-level read access to the MSRs. Hypervisors may choose to remove access to these MSRs for untrusted guests.

Hence I will go update the description to also include the importance of blocking even user read access given malicious application can abuse these. Would you agree?

Regarding, the 9p module I will uncomment it with added description and thanks for reminding me about the new changes to packaging and this correction will be done.

Please let me know if you have any further suggestions.

[ArrayBolt3]

As a general rule, the attack scenarios from malicious unprivileged applications to other trust domains can be blocked by removing user-level read access to the MSRs. Hypervisors may choose to remove access to these MSRs for untrusted guests.

Hence I will go update the description to also include the importance of blocking even user read access given malicious application can abuse these. Would you agree?

Yes, that makes good sense to me.

[ArrayBolt3]

Merged into my arraybolt3/trixie branch, thank you!