linux-kernel - Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

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:	Fri, 4 Apr 2014 16:17:50 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Joerg Roedel <joro@...tes.org>, Jiri Kosina <jkosina@...e.cz>,
	Mateusz Guzik <mguzik@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
	Ingo Molnar <mingo@...nel.org>, Mel Gorman <mgorman@...e.de>,
	Kay Sievers <kay@...y.org>
Subject: Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

On Fri, Apr 04, 2014 at 03:44:26PM -0400, Steven Rostedt wrote:
> I saw one commenter say that this was a kernel bug because writing to
> kmsg shouldn't cause the system to hang.
> 
> The rate-limit patch would go along with that idea, and I honestly
> think it would be good to rate-limit it in case something else breaks
> and starts spamming kmsg.

I agree; the only question is what is the appropriate rate limits,
which is the question Linus was asking.

Personally, I like keeping the current limits (no more than ten
messages every 5 seconds) because I don't think dmesg, which is a
circular buffer and deliberately kept simple so that printk is
guaranteed to work even when things go really bad (and if things do go
really bad, there are ways of reading dmesg out from a crash dump, for
example, so we want to keep things simple).

Peter has argued that it might be cool if the Kernel had a
purpose-built in-kernel syslogd sort of interface, that could accept
arbitrarily large amounts of data, and presumably it would allocate
memory as needed, and since the kernel knows this is log data, if we
are under memory pressure, it could release some of the log data, even
if the userspace hasn't picked it up yet, under extreme memory
pressure.

I don't know that it makes sense to do this, since IMHO we can just as
easily do this in a user-space process.

But I *do* think we should keep the facility used by printk to be as
simple and as bulletproof as possible, which means we should really
try to keep users of /dev/kmesg to the simple "I'm starting test
<foo>", or similar messages.  And that argues for using things like
the current ratelimit defaults.

							- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/