Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764613AbXEYRwS (ORCPT ); Fri, 25 May 2007 13:52:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761972AbXEYRwE (ORCPT ); Fri, 25 May 2007 13:52:04 -0400 Received: from smtp1.linux-foundation.org ([207.189.120.13]:46855 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751433AbXEYRwC (ORCPT ); Fri, 25 May 2007 13:52:02 -0400 Date: Fri, 25 May 2007 10:50:38 -0700 (PDT) From: Linus Torvalds To: Andrew Morton cc: Alan Cox , Chris Newport , Ingo Molnar , Christoph Lameter , Michal Piotrowski , LKML , "Cherwin R. Nooitmeer" , linux-pcmcia@lists.infradead.org, Robert de Rooy , Alan Cox , Tejun Heo , sparclinux@vger.kernel.org, David Miller , Mikael Pettersson , linux1394-devel@lists.sourceforge.net, Stefan Richter , Kristian H?gsberg , linux-pm@lists.linux-foundation.org, "Rafael J. Wysocki" , Pavel Machek , Marcus Better , Andrey Borzenkov , linux-usb-devel@lists.sourceforge.net, Greg Kroah-Hartman Subject: Re: [2/3] 2.6.22-rc2: known regressions v2 In-Reply-To: <20070525103714.092ad631.akpm@linux-foundation.org> Message-ID: References: <46558708.2040803@googlemail.com> <46559B54.80106@googlemail.com> <20070524193740.GA6787@elte.hu> <20070525101105.GA9268@elte.hu> <4656CE39.8050800@netunix.com> <20070525180304.2cc4dae0@the-village.bc.nu> <20070525103714.092ad631.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3460 Lines: 87 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. > You can learn a hell of a lot by really carefully picking through kernel > memory with gdb. .. but you can learn equally much with other methods that do *not* involve the pain and suffering that is a kernel dump. Setting up netconsole or the firewire tools is much easier. The firewire thing in particular is nice, because it doesn't actually rely on the target having to even know about it (other than enabling the "remote DMA access" thing once on bootup). If you've ever picked through a kernel dump after-the-fact, I just bet you could have done equally well with firewire, and it would have had _zero_ impact on your kernel image. Now, contrast that with kdump, and ask yourself: which one do you think is worth concentrating effort on? - kdump: lots of code and maintenance effort, doesn't work if the CPU locks up, requires a lot of learning to go through the dump. - firewire: zero code, no maintenance effort, works even if the CPU locks up. Still does require the same learning to go through the end result. Which one wins? I know which one I'll push. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/