linux-kernel - Re: [RFC][PATCH] printk: increase devkmsg write() ratelimit

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]

Date:   Thu, 20 Dec 2018 08:58:03 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Borislav Petkov <bp@...en8.de>, Petr Mladek <pmladek@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] printk: increase devkmsg write() ratelimit

On Thu, 20 Dec 2018 20:35:37 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> wrote:

> On (12/18/18 12:37), Steven Rostedt wrote:
> > > 
> > > Again, complain to system-doofus for printing so much crap to somewhere
> > > it should not print to begin with.  
> > 
> > I've been saying that it would be good to make the kmsg be a separate
> > buffer that just gets interleaved with the kernel buffer.  
> 
> Hmm, this is interesting.
> 
> > Userspace processes should never be able to overwrite messages
> > from the kernel.  
> 
> I would agree.
> 
> It's a bit funny that kernel people first take the patch in and then,
> when user-space begins to use the feature, start to object and ratelimit.

Please note the "kernel people" to first take it in, were also systemd
developers. And there was a bit of objections to what they wanted to
have to what they got. It wasn't until later when systemd started
abusing the buffer (taking it as its own, making the kernel use of it a
second class citizen) that other kernel developers (that now need to
deal with the fallout) started to object and ratelimit it.

Honestly, it should have been a separate buffer to begin with, and I
wish I pushed for that when it was first added. It's not too late. We
can still make it a separate buffer.

> 
> By the way, systemd seems to be OK with alternative logging targets
> 
> /etc/systemd/system.conf
> 
> ---
> 	[Manager]
> 	#LogLevel=info
> 	LogTarget=syslog console journal

When the system is up and running, it works. But I believe systemd can
still only use ksmsg for initial boot up messages before it does the
chroot.

> ---
> 
> Everything looks fine with read-only devkmsg (running the patched
> kernel). "journalctl -f -b" gives a nice system log:
> 
> ...
>  kernel: r8169 0000:04:00.0 enp4s0: renamed from eth0
>  kernel: snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a
>  systemd-udevd[180]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
>  systemd[1]: Started Flush Journal to Persistent Storage.
>  kernel: input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7
> ...
> 

Do you get systemd messages before chroot with this patch compared to
what you get without it?

-- Steve

> 
> Given how often systemd hits ratelimits (I googled some bug reports),
> I wonder if systemd people are still interested in /dev/kmsg logging
> at all.
>