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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 3 Apr 2014 13:05:42 -0400
From:	Theodore Ts'o <>
To:	Joerg Roedel <>
Cc:	Linus Torvalds <>,
	Jiri Kosina <>,
	Andrew Morton <>,
	Mateusz Guzik <>,
	Greg Kroah-Hartman <>,
	Steven Rostedt <>,
	LKML <>,
	Thomas Gleixner <>,
	"H. Peter Anvin" <>, Borislav Petkov <>,
	Ingo Molnar <>, Mel Gorman <>,
	Kay Sievers <>
Subject: Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

On Thu, Apr 03, 2014 at 12:43:08PM +0200, Joerg Roedel wrote:
> How about just ignoring writes to /dev/kmsg altogether by default
> (unless explicitly enabled in Kconfig or on the kernel cmdline)? Maybe I
> am missing something but what are the legitimate use-cases for generally
> allowing user-space to write into the kernel-log?

I'll give you one example which where /dev/kmesg is useful --- if you
are running automated kernel tests, echoing "running test shared/127"
.... several minutes later .... "running test shared/128", is very
useful since if the kernel starts spewing warnings, or even
oops/panics/livelocks, you know what test was running at the time of
the failure.

So in general, most of the valid use cases I can see for /dev/kmesg
are small amounts of information where understanding the relationship
between what is going in userspace can help understand the kernel
warnings, errors, or other printk messages.  Which is why I think rate
limiting, even with a very low threshold, is a perfectly good alternative.

If you need to do bulk logging, and the problem is you want to make
sure the information doesn't get lost because syslogd/journald hasn't
started up yet, or the file system hasn't been remounted read/write
yet, there is a simple answer to this, and it doesn't involve spamming
the kernel ring buffer (because kernel memory is non-swappable).

The answer is logsave(8), which I developed to solve this specific
problem.  I wanted to make sure distributions could capture the output
of fsck, even when checking the read-only root file system.  Note that
I did not even *consider* spamming the dmesg log with e2fsck output.
Instead, I created a userspace logsave process which could buffer the
output (which of course was still displayed on the console) until the
root file system was writeable (and/or /var was mounted), at which
point the contents could be saved to a file in /var/log.

So there are so many other ways of solving this problem without trying
to abuse the kernel logging facilities (which were never intended to
be a general-purpose syslog replacement).  I suspect some systemd
developer was being lazy....

					- Ted
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists