linux-kernel - Re: [PATCH 3/9] printk: add CON

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: <20130301161538.GA16393@logfs.org>
Date:	Fri, 1 Mar 2013 11:15:38 -0500
From:	Jörn Engel <joern@...fs.org>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 3/9] printk: add CON_ALLDATA console flag

On Fri, 1 March 2013 10:08:00 -0500, Jeff Moyer wrote:
> 
> People don't just use this for "debugging sessions."  They use it in
> production, and I already gave you one reason why you might not want to
> do this with netconsole (udp is unreliable, and I've definitely seem
> cases where netconsole suffered due to dropped packets; this won't make
> that better, especially when you multiply the extra bytes times the
> number of servers on the subnet).

I think I maintain a fairly sizeable production setup with netconsole.
A few hundred machines run netconsole and send all messages to a
single recipient.  And all those machines have the patch we are
discussing applied.  That has caused roughly zero problems so far.

We constantly see problems with netconsole and presumably packet loss
(haven't checked yet) when show_state() runs.  That amount of load
appears to be too much for the network.  Regular production netconsole
is utterly unimpressed in my network, with or without CON_ALLDATA.

Which is not to say you are wrong.  It just means that noone has shown
an example supporting your argument yet, while I have one supporting
mine.

More fundamentally, I believe the console log levels used to make
sense when systems had exactly one console.  With multiple consoles
and vastly different properties of those consoles, you simply cannot
find one good answer for all.  A 9600 baud serial console will usually
add several seconds to your boot process, so eliminating extra
messages is hugely important.  Blockconsole can take several megabytes
a second without blinking, so the cost of extra messages is near-zero,
while the benefit remains identical.

Maybe the correct solution would be to have a separate loglevel for
each console.  I don't know.  For my purposes the coarser CON_ALLDATA
approach is good enough.

Jörn

--
"Security vulnerabilities are here to stay."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
--
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/