linux-kernel - Re: [2/3] 2.6.22-rc2: known regressions v2

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: <20070528042747.GB6367@in.ibm.com>
Date:	Mon, 28 May 2007 09:57:48 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Chris Newport <crn@...unix.com>, Ingo Molnar <mingo@...e.hu>,
	Christoph Lameter <clameter@....com>,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Cherwin R. Nooitmeer" <cherwin@...il.com>,
	linux-pcmcia@...ts.infradead.org,
	Robert de Rooy <robert.de.rooy@...il.com>,
	Alan Cox <alan@...hat.com>, Tejun Heo <htejun@...il.com>,
	sparclinux@...r.kernel.org, David Miller <davem@...emloft.net>,
	Mikael Pettersson <mikpe@...uu.se>,
	linux1394-devel@...ts.sourceforge.net,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Kristian H?gsberg <krh@...planet.net>,
	linux-pm@...ts.linux-foundation.org,
	"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@....cz>,
	Marcus Better <marcus@...ter.se>,
	Andrey Borzenkov <arvidjaar@...l.ru>,
	linux-usb-devel@...ts.sourceforge.net,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [2/3] 2.6.22-rc2: known regressions v2

On Fri, May 25, 2007 at 10:50:38AM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 25 May 2007, Andrew Morton wrote:
> >
> > > > There is an additional factor - dumps contain data which variously is -
> > > > copyright third parties, protected by privacy laws, just personally
> > > > private, security sensitive (eg browser history) and so on.
> > > 
> > > Yes. 
> > 
> > We're uninterested in pagecache and user memory and they should be omitted
> > from the image (making it enormously smaller too).
> 
> The people who would use crash-dumps (big sensitive firms) don't trust 
> you.
> 
> And they'd be right not to trust you. You end up having a _lot_ of 
> sensitive data even if you avoid user memory and page cache. The network 
> buffers, the dentries, and just stale data that hasn't been overwritten.
> 
> So if you end up having secure data on that machine, you should *never* 
> send a dump to somebody you don't trust. For the financial companies 
> (which are practically the only ones that would use dumps) there can even 
> be legal reasons why they cannot do that!
> 
> > That leaves security keys and perhaps filenames, and these could probably
> > be addressed.
> 
> It leaves almost every single kernel allocation, and no, it cannot be 
> addressed.
> 
> How are you going to clear out the network packets that you have in 
> memory? They're just kmalloc'ed. 
> 
> > > I'm sure we've had one or two crashdumps over the years that have actually 
> > > clarified a bug.
> > > 
> > > But I seriously doubt it is more than a handful. 
> > 
> > We've had a few more than that, but all the ones I recall actually came
> > from the kdump developers who were hitting other bugs and who just happened
> > to know how to drive the thing.
> 
> Right, I don't dispute that some _developers_ might use dumping. I dispute 
> that any user would practically ever use it.
> 
> And even for developers, I suspect it's _so_ far down the list of things 
> you do, that it's practically zero.
> 
> > > But 99% of the time, the problem doesn't happen on a developer machine, 
> > > and even if it does, 90% of the time you really just want the traceback 
> > > and register info that you get out of an oops.
> > 
> > Often we don't even get that: "I was in X and it didn't hit the logs".
> 
> Yes. 
> 

Isn't it reason enough for customers to use it? How will a customer 
capture even an OOPS meesage? Lets say some web server crashed and OOPs 
message did not make it to logs. I am not expecting a customer to setup
a console for each and every machine in the network. In this scenario
customer will have no choice but to reset the machine without any
information about why did machine crash.

If one can keep kdump configured, upon a crash there are high chances
that customer will have some debug information to look at. I agree that
security of data can be a concern. In that case probably one can extract
a small dump report, like OOPs message, messages in the kernel buffers
just before crash etc. and report it to service folks. 

Without kdump, customer will most likely have no debug data except a
complain that system crashed and rebooted or it had to be reset by manual
intervention.

Thanks
Vivek
-
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/