linux-kernel - Re: [PATCH] printk: robustify printk

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: <20080811120231.GC23529@elte.hu>
Date:	Mon, 11 Aug 2008 14:02:31 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org, tglx@...utronix.de,
	marcin.slusarz@...il.com, linux-kernel@...r.kernel.org,
	davem@...emloft.net, rostedt@...dmis.org,
	paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH] printk: robustify printk

* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> > The problem is that it means any printk data output that is more 
> > than DMESG-BUFFER-SIZE bytes during one clock tick is going to lose 
> > data. It loses the natural adaption to higher printk rates that you 
> > got previously.
> > 
> > Now we could say that for debugging etc. people should switch to 
> > other mechanisms like relayfs, but I would still worry about some 
> > corner cases where losing printk data that wasn't lost before could 
> > be a severe regression (e.g. consider firewall log messages or 
> > similar)

That's a rather misleading argument, because klogd as it stands today is 
already lossy: you can overflow it with enough printk data. (It's rather 
easy to trigger it as well, so nobody sane relies on it as a reliable 
channel.)

Using relayfs and dynamic buffers would be a much worse approach because 
if we are out of buffer space it would be a robustness disaster to start 
allocating more RAM. (we want less coupling of printk to other kernel 
subsystems, not more coupling) Preallocating wont help either because it 
doesnt protect against sudden spikes.

> You only loose the msgs with klogd, console still gets everything. If 
> firewalls are generating that much data, perhaps its time to think 
> about alternative ways to channel that.

yeah, and note that klogd as it stands today is a lossy channel no 
matter what - there's nothing that keeps a really verbose kernel from 
flooding the buffer.

The issue Andi raises is largely independent of this change and there's 
three clean options to deal with it:

 - increase buffering (already possible, see CONFIG_LOG_BUF_SHIFT)

 - create a more reliable klogd channel with a dynamically
   shrinking/growing buffer (i very much doubt the complexity is
   worth it, and this one wont be 100% loss-less either)

 - use a reliable console

#1 is what distros use to maximize the yield of user bugreports, and #3
is what everyone who ultimately cares about massive printk output and 
reliable logging uses.

	Ingo
--
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/