[PATCH v2] lockdown: Only log restrictions once

Daniel Tang posted 1 patch 1 week, 5 days ago
security/lockdown/lockdown.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
[PATCH v2] lockdown: Only log restrictions once
Posted by Daniel Tang 1 week, 5 days ago
KDE's lockscreen causes systemd-logind to spam dmesg about hibernation.
systemd declined to cache /sys/power/state due to runtime changeability.

Link: https://github.com/systemd/systemd/pull/39802
Signed-off-by: Daniel Tang <danielzgtg.opensource@gmail.com>
---
 security/lockdown/lockdown.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index cf83afa1d879..83b50de52f21 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -58,13 +58,16 @@ early_param("lockdown", lockdown_param);
  */
 static int lockdown_is_locked_down(enum lockdown_reason what)
 {
+	static volatile unsigned long lockdown_reasons_seen;
+	static_assert(ARRAY_SIZE(lockdown_reasons) < sizeof(lockdown_reasons_seen) * 8);
+
 	if (WARN(what >= LOCKDOWN_CONFIDENTIALITY_MAX,
 		 "Invalid lockdown reason"))
 		return -EPERM;
 
 	if (kernel_locked_down >= what) {
-		if (lockdown_reasons[what])
-			pr_notice_ratelimited("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n",
+		if (lockdown_reasons[what] && !test_and_set_bit(what, &lockdown_reasons_seen))
+			pr_notice("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n",
 				  current->comm, lockdown_reasons[what]);
 		return -EPERM;
 	}
-- 
2.51.0
Re: [PATCH v2] lockdown: Only log restrictions once
Posted by Xiujianfeng 1 week, 4 days ago
Hi Daniel,

On 11/20/2025 2:07 AM, Daniel Tang wrote:
> KDE's lockscreen causes systemd-logind to spam dmesg about hibernation.
> systemd declined to cache /sys/power/state due to runtime changeability.
> 
> Link: https://github.com/systemd/systemd/pull/39802
> Signed-off-by: Daniel Tang <danielzgtg.opensource@gmail.com>
> ---
>   security/lockdown/lockdown.c | 7 +++++--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
> index cf83afa1d879..83b50de52f21 100644
> --- a/security/lockdown/lockdown.c
> +++ b/security/lockdown/lockdown.c
> @@ -58,13 +58,16 @@ early_param("lockdown", lockdown_param);
>    */
>   static int lockdown_is_locked_down(enum lockdown_reason what)
>   {
> +	static volatile unsigned long lockdown_reasons_seen;
> +	static_assert(ARRAY_SIZE(lockdown_reasons) < sizeof(lockdown_reasons_seen) * 8);
> +
>   	if (WARN(what >= LOCKDOWN_CONFIDENTIALITY_MAX,
>   		 "Invalid lockdown reason"))
>   		return -EPERM;
>   
>   	if (kernel_locked_down >= what) {
> -		if (lockdown_reasons[what])
> -			pr_notice_ratelimited("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n",
> +		if (lockdown_reasons[what] && !test_and_set_bit(what, &lockdown_reasons_seen))
> +			pr_notice("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n",
>   				  current->comm, lockdown_reasons[what]);

Currently lockdown does not support the audit function, so I believe the
logs here serve a purpose similar to auditing. Based on this, I think
this change will meaningfully degrade the quality of the logs, making it
hard for users to find out what happens when lockdown is active,
especially after a long time running.

Is it possible to adjust the printk_ratelimit & printk_ratelimit_burst
in /proc/sys/kernel/ to reduce the logs in your scenario?

Anyway, I will wait for Nicolas's comment.
>   		return -EPERM;
>   	}

Re: [PATCH v2] lockdown: Only log restrictions once
Posted by Nicolas Bouchinet 6 days, 16 hours ago
Hi,

> Currently lockdown does not support the audit function, so I believe the
> logs here serve a purpose similar to auditing. Based on this, I think
> this change will meaningfully degrade the quality of the logs, making it
> hard for users to find out what happens when lockdown is active,
> especially after a long time running.
I agree with Xiu.
I'm not sure to understand how this is a kernel issue. I mean beside
that we do not support hibernation in Lockdown for now.
Can't you just disable hibernation with systemd-logind using someting like
'AllowHibernation=no' ?

Best regards,

Nicolas
Re: [PATCH v2] lockdown: Only log restrictions once
Posted by Daniel Tang 1 week, 4 days ago
On Thursday, 20 November 2025, 02:37:56 EST Xiujianfeng <xiujianfeng@huaweicloud.com> wrote:
> Is it possible to adjust the printk_ratelimit & printk_ratelimit_burst
> in /proc/sys/kernel/ to reduce the logs in your scenario?

It's not working. Watching the console after setting the sysctl and
repeatedly clicking org.freedesktop.login1.Manager.CanSuspend in
qdbusviewer (simulating what the lockscreen does), I see:

```console
root@daniel-desktop3:~# uname -a
Linux daniel-desktop3 6.17.0-6-generic #6-Ubuntu SMP PREEMPT_DYNAMIC Tue Oct  7 13:34:17 UTC 2025 x86_64 GNU/Linux
root@daniel-desktop3:~# sysctl kernel.printk_ratelimit_burst=1
kernel.printk_ratelimit_burst = 1
root@daniel-desktop3:~# sysctl kernel.printk_ratelimit=999999
kernel.printk_ratelimit = 999999
root@daniel-desktop3:~# dmesg -W
[14385.334698] lockdown_is_locked_down: 3 callbacks suppressed
[14385.334701] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14385.614738] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14385.878857] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14386.166744] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14386.454771] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14386.750900] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14387.038795] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14387.334770] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14387.622696] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14387.926763] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14390.366582] lockdown_is_locked_down: 7 callbacks suppressed
[14390.366585] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14390.798744] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14391.118802] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14391.422728] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14391.742754] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14392.046735] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14392.350745] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14392.654992] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14392.974797] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[14393.270741] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
```

At my desk, I lock my screen every 5 hours. In public, I might lock my
screen every 1 minute, 5 minute, or 15 *minutes*. printk_ratelimit
seems to be targeted towards things that happen every N *seconds*.

> logs here serve a purpose similar to auditing. Based on this, I think
> this change will meaningfully degrade the quality of the logs, making it
> hard for users to find out what happens when lockdown is active,
> especially after a long time running.

For v3 in December, I'm thinking of adding a code path to special-case
*reads* from /sys/power/state. What do you think?
Re: [PATCH v2] lockdown: Only log restrictions once
Posted by Xiujianfeng 1 week, 4 days ago
Hi Daniel,

On 11/20/2025 5:26 PM, Daniel Tang wrote:
> On Thursday, 20 November 2025, 02:37:56 EST Xiujianfeng <xiujianfeng@huaweicloud.com> wrote:
>> Is it possible to adjust the printk_ratelimit & printk_ratelimit_burst
>> in /proc/sys/kernel/ to reduce the logs in your scenario?
> 
> It's not working. Watching the console after setting the sysctl and
> repeatedly clicking org.freedesktop.login1.Manager.CanSuspend in
> qdbusviewer (simulating what the lockscreen does), I see:
> 
> ```console
> root@daniel-desktop3:~# uname -a
> Linux daniel-desktop3 6.17.0-6-generic #6-Ubuntu SMP PREEMPT_DYNAMIC Tue Oct  7 13:34:17 UTC 2025 x86_64 GNU/Linux
> root@daniel-desktop3:~# sysctl kernel.printk_ratelimit_burst=1
> kernel.printk_ratelimit_burst = 1
> root@daniel-desktop3:~# sysctl kernel.printk_ratelimit=999999
> kernel.printk_ratelimit = 999999
> root@daniel-desktop3:~# dmesg -W
> [14385.334698] lockdown_is_locked_down: 3 callbacks suppressed
> [14385.334701] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14385.614738] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14385.878857] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14386.166744] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14386.454771] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14386.750900] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14387.038795] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14387.334770] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14387.622696] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14387.926763] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14390.366582] lockdown_is_locked_down: 7 callbacks suppressed
> [14390.366585] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14390.798744] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14391.118802] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14391.422728] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14391.742754] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14392.046735] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14392.350745] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14392.654992] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14392.974797] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> [14393.270741] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> ```
> 
> At my desk, I lock my screen every 5 hours. In public, I might lock my
> screen every 1 minute, 5 minute, or 15 *minutes*. printk_ratelimit
> seems to be targeted towards things that happen every N *seconds*.

Sorry for misleading.

After reading the code, I found that the macro of printk_ratelimited is

#define printk_ratelimited(fmt, ...)                                    \
({                                                                      \
         static DEFINE_RATELIMIT_STATE(_rs,                              \
                                       DEFAULT_RATELIMIT_INTERVAL,       \
                                       DEFAULT_RATELIMIT_BURST);         \
                                                                         \
         if (__ratelimit(&_rs))                                          \
                 printk(fmt, ##__VA_ARGS__);                             \
})

It seems that the rate is fixed and can not be modified via sysctl.
While another interface with a modifiable rate, which is
printk_ratelimit(), is marked as "don't use".

> 
>> logs here serve a purpose similar to auditing. Based on this, I think
>> this change will meaningfully degrade the quality of the logs, making it
>> hard for users to find out what happens when lockdown is active,
>> especially after a long time running.
> 
> For v3 in December, I'm thinking of adding a code path to special-case
> *reads* from /sys/power/state. What do you think?

Sorry, I am not familiar with hibernation, maybe you can CC hibernation
maintainers.

>