From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55903 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OSD2e-0005eG-NB for qemu-devel@nongnu.org; Fri, 25 Jun 2010 13:50:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OS8Az-0001nm-Te for qemu-devel@nongnu.org; Fri, 25 Jun 2010 08:38:35 -0400 Received: from e23smtp06.au.ibm.com ([202.81.31.148]:39240) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OS8Az-0001k6-C5 for qemu-devel@nongnu.org; Fri, 25 Jun 2010 08:38:33 -0400 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp06.au.ibm.com (8.14.4/8.13.1) with ESMTP id o5PCcB76011467 for ; Fri, 25 Jun 2010 22:38:11 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5PCcIps1146918 for ; Fri, 25 Jun 2010 22:38:19 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5PCcIrY012168 for ; Fri, 25 Jun 2010 22:38:18 +1000 Message-ID: <4C24A337.7090201@linux.vnet.ibm.com> Date: Fri, 25 Jun 2010 18:08:15 +0530 From: Mahesh Jagannath Salgaonkar MIME-Version: 1.0 Subject: Re: [Qemu-devel] [patch 2/3] QEMU-C-F: Introducing qemu userspace tool qemu-core-filter. References: <20100622040018.044362998@mars.in.ibm.com> <20100622040154.GC27051@in.ibm.com> <4C20B478.4020701@linux.vnet.ibm.com> In-Reply-To: <4C20B478.4020701@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Maneesh Soni , Reinhard Buendgen , qemu-devel@nongnu.org, Michael Mueller , Ananth N Mavinakayanahalli On 06/22/2010 06:32 PM, Anthony Liguori wrote: > Hrm, the way you've sent this patch makes Thunderbird unhappy. It > appears the whole thing is treated as an attachment. In the future, I'd > suggest avoiding the Content-Disposition tag > Sure. I will take care of this in future. > On 06/21/2010 11:01 PM, Mahesh Salgaonkar wrote: >> Qemu userspace tool to filter out guest OS memory from qemu core file. >> Use '--enable-core-filter' option while running ./configure script to >> build >> qemu-core-filter tool. This is a post-processing tool works offline on >> qemu >> coredumps. This tool helps to reuce the size of qemu core file >> (generated by >> qemu crash) by removing guest OS memory from original core file. >> >> Currently it is only supported for Linux on x86 and x86_64. > > There are a few problems with a tool like this. The first is that it > depends on very specific internals of qemu (namely, the way we allocate > ram). If we applied this, we would get subtle breakages if we made even > the slightest changes to qemu. > This is the precise reason we would like to get this tool integrated into QEMU sources. So, whenever something changes in qemu, then this tool can be modified accordingly. > IMHO, the value is also questionable. There is quite a bit of sensitive > data left in the core file after removing guest memory. Any DMA buffer > may contain very sensitive data (for instance, if you crash during a > read of /etc/shadow). Even the CPU registers can contain sensitive data. > > I think the only really viable approach to this problem is to take a > white list approach instead of a black list approach. That means > extracting useful information that we're reasonably confident preserves > privacy. That would be information like a back trace, the crash reason, > etc. Tools like apport and ABT already do exactly this and they also > present an interface to the user to validate the data before sending it. > They also provide a way to collect other information (like host dmesg). > I understand your point but this tool can be of interest of people who sends out large coredump files to service centers for initial analysis. This tool will help them to reduce the size of core file before sending it to service centers for analysis. What do you think? > Regards, > > Anthony Liguori Regards, -Mahesh.