public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Tang <danielzgtg.opensource@gmail.com>
To: Nicolas Bouchinet <nicolas.bouchinet@oss.cyber.gouv.fr>,
	Xiu Jianfeng <xiujianfeng@huawei.com>,
	Paul Moore <paul@paul-moore.com>,
	Xiujianfeng <xiujianfeng@huaweicloud.com>
Cc: linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Nathan Lynch <nathanl@linux.ibm.com>,
	Matthew Garrett <mjg59@google.com>,
	Kees Cook <keescook@chromium.org>,
	David Howells <dhowells@redhat.com>,
	James Morris <jmorris@namei.org>
Subject: Re: [PATCH v2] lockdown: Only log restrictions once
Date: Thu, 20 Nov 2025 04:26:45 -0500	[thread overview]
Message-ID: <7645139.4DdEvYhyI6@daniel-desktop3> (raw)
In-Reply-To: <2f4a1af8-adc6-4cbc-813f-4cc8e9bc75ae@huaweicloud.com>

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?



  reply	other threads:[~2025-11-20  9:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19 13:22 [PATCH] lockdown: Only log restrictions once Daniel Tang
2025-11-19 16:05 ` Paul Moore
2025-11-19 18:07   ` [PATCH v2] " Daniel Tang
2025-11-20  7:37     ` Xiujianfeng
2025-11-20  9:26       ` Daniel Tang [this message]
2025-11-20 13:35         ` Xiujianfeng
2025-11-25 10:00       ` Nicolas Bouchinet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7645139.4DdEvYhyI6@daniel-desktop3 \
    --to=danielzgtg.opensource@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mjg59@google.com \
    --cc=nathanl@linux.ibm.com \
    --cc=nicolas.bouchinet@oss.cyber.gouv.fr \
    --cc=paul@paul-moore.com \
    --cc=xiujianfeng@huawei.com \
    --cc=xiujianfeng@huaweicloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox