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 15:45:08 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Steven Rostedt <rostedt@...dmis.org>,
	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 4, 2014 at 1:17 PM, Theodore Ts'o <tytso@....edu> wrote:
> 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.

can there be two bulletproof buffers: one for in kernel printk
and another ratelimited one for writes into /dev/kmsg.
On the read from /dev/kmsg they're combined by time.
--
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/