Subject: x86/msr + lockdown: allow access to **documented** RAPL/TCC controls under Secure Boot

Subject: x86/msr + lockdown: allow access to **documented** RAPL/TCC controls under Secure Boot

[Artem S. Tashkinov]

Hello,

When Secure Boot is enabled and kernel lockdown is active, the x86 MSR 
driver blocks all raw MSR access from user space via `/dev/cpu/*/msr`. 
This effectively prevents legitimate use of documented CPU power and 
thermal management interfaces such as RAPL power limits (PL1/PL2) and 
the TCC/TjOffset control. These registers are part of Intel’s 
**publicly** documented architectural interface and have been stable 
across many generations of processors.

As a result, under Secure Boot Linux users lose the ability to read or 
adjust **standard** power-management controls that remain available 
through equivalent tooling on other operating systems.

The current all-or-nothing restriction appears broader than necessary 
for the stated goal of protecting kernel integrity. MSRs associated with 
power limits and TCC offset are not privileged debugging or microcode 
interfaces but standard hardware configuration knobs intended for 
platform power and thermal management.

It would be useful if the kernel either allowed access to a small 
whitelist of such documented registers under lockdown or exposed a 
mediated kernel interface for adjusting them. Without such a mechanism, 
Secure Boot effectively disables legitimate and widely used 
power/thermal tuning functionality on modern Intel laptops.

Most (if not all) Intel laptops don't expose or allow to configure 
PL1/PL2 limits in BIOS/EFI either.

This is being tracked here: 
https://bugzilla.kernel.org/show_bug.cgi?id=221192

Regards,
Artem

Re: Subject: x86/msr + lockdown: allow access to **documented** RAPL/TCC controls under Secure Boot

[Rafael J. Wysocki]

On Mon, Mar 9, 2026 at 1:24 PM Artem S. Tashkinov <aros@gmx.com> wrote:
>
> Hello,
>
> When Secure Boot is enabled and kernel lockdown is active, the x86 MSR
> driver blocks all raw MSR access from user space via `/dev/cpu/*/msr`.
> This effectively prevents legitimate use of documented CPU power and
> thermal management interfaces such as RAPL power limits (PL1/PL2) and
> the TCC/TjOffset control. These registers are part of Intel’s
> **publicly** documented architectural interface and have been stable
> across many generations of processors.

There is a power capping RAPL driver.  What's the problem with it with
Secure Boot enabled?

> As a result, under Secure Boot Linux users lose the ability to read or
> adjust **standard** power-management controls that remain available
> through equivalent tooling on other operating systems.

The power capping RAPL driver is there, please use it.  It is documented even.

There is also a driver for TCC/TjOffset control, it is called intel_tcc_cooling.

And there are utilities in user space (for example, Intel thermald)
that use those interfaces.

> The current all-or-nothing restriction appears broader than necessary
> for the stated goal of protecting kernel integrity. MSRs associated with
> power limits and TCC offset are not privileged debugging or microcode
> interfaces but standard hardware configuration knobs intended for
> platform power and thermal management.
>
> It would be useful if the kernel either allowed access to a small
> whitelist of such documented registers under lockdown or exposed a
> mediated kernel interface for adjusting them. Without such a mechanism,
> Secure Boot effectively disables legitimate and widely used
> power/thermal tuning functionality on modern Intel laptops.
>
> Most (if not all) Intel laptops don't expose or allow to configure
> PL1/PL2 limits in BIOS/EFI either.

Because it is not necessary to do so.

Re: Subject: x86/msr + lockdown: allow access to **documented** RAPL/TCC controls under Secure Boot

[bauen1]

On 3/9/26 4:13 PM, Rafael J. Wysocki wrote:
> On Mon, Mar 9, 2026 at 1:24 PM Artem S. Tashkinov <aros@gmx.com> wrote:
>>
>> Hello,
>>
>> When Secure Boot is enabled and kernel lockdown is active, the x86 MSR
>> driver blocks all raw MSR access from user space via `/dev/cpu/*/msr`.
>> This effectively prevents legitimate use of documented CPU power and
>> thermal management interfaces such as RAPL power limits (PL1/PL2) and
>> the TCC/TjOffset control. These registers are part of Intel’s
>> **publicly** documented architectural interface and have been stable
>> across many generations of processors.
> 
> There is a power capping RAPL driver.  What's the problem with it with
> Secure Boot enabled?

Hello,

I believe that the comment about Secure Boot might come from the partially
incorrect documentation of lockdown:

https://lore.kernel.org/linux-security-module/20260203195001.20131-1-hi@alyssa.is/

> -On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled
> -if the system boots in EFI Secure Boot mode.

> This is true for Fedora, where this page was sourced from, but I don't
> believe it has ever been true for the mainline kernel, because Linus
> rejected it.



> 
>> As a result, under Secure Boot Linux users lose the ability to read or
>> adjust **standard** power-management controls that remain available
>> through equivalent tooling on other operating systems.
> 
> The power capping RAPL driver is there, please use it.  It is documented even.
> 
> There is also a driver for TCC/TjOffset control, it is called intel_tcc_cooling.
> 
> And there are utilities in user space (for example, Intel thermald)
> that use those interfaces.
> 
>> The current all-or-nothing restriction appears broader than necessary
>> for the stated goal of protecting kernel integrity. MSRs associated with
>> power limits and TCC offset are not privileged debugging or microcode
>> interfaces but standard hardware configuration knobs intended for
>> platform power and thermal management.
>>
>> It would be useful if the kernel either allowed access to a small
>> whitelist of such documented registers under lockdown or exposed a
>> mediated kernel interface for adjusting them. Without such a mechanism,
>> Secure Boot effectively disables legitimate and widely used
>> power/thermal tuning functionality on modern Intel laptops.
>>
>> Most (if not all) Intel laptops don't expose or allow to configure
>> PL1/PL2 limits in BIOS/EFI either.
> 
> Because it is not necessary to do so.
> 


-- 
bauen1