lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YHVnQfQ4zDt09RFe@alley>
Date:   Tue, 13 Apr 2021 11:41:21 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Samo Pogačnik <samo_pogacnik@....net>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Jiri Slaby <jirislaby@...nel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Ogness <john.ogness@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: How to handle concurrent access to /dev/ttyprintk ?

On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote:
> Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a):
> > What is the intended usage of /dev/ttyprintk ?
> > 
> 
> The intended use of 'ttyprintk' is to redirect console to /dev/ttyprintk
> via the TIOCCONS ioctl. After successfull redirection, all console
> messages get "merged" with kernel messages and as such automatically processed
> (stored/transferred) by the syslog service for example.

The same can be achieved by /dev/kmsg that was created by systemd
developers.

systemd is able to flood the kernel buffer and consoles.
It can be protected by ratelimiting, see the commit
750afe7babd117daabebf ("printk: add kernel parameter
to control writes to /dev/kmsg").

/dev/kmsg ratelimit is a "must-to-have". systemd enables debug
messages using the same "debug" parameter passed on the kernel
commandline. The ratelimit allows to see the kernel messages.

Note that the ratelimit is enabled by default by kernel. But it
it disabled by default by systemd. So, it is effectively disabled
by default.

It might be possible to add retalimiting also for /dev/ttyprintk.
But does it make sense just because of an artifical test case?


History:

/dev/ttyprintk has been added in v2.6.37 (2010)  by commit 24b4b67d17c308aaa956b
("add ttyprintk driver")

/dev/kmsg has been add in v3.5-rc1 (2012) by commit e11fea92e13fb91c50ba
("kmsg: export printk records to the /dev/kmsg interface")

Another solution might be to obsolete /dev/ttyprintk by /dev/kmsg.
We have to preserve /dev/kmsg because of systemd.
Is anyone really using /dev/ttyprintk these days?

Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ