On 2011-05-26 09:39:23 Thu, Vivek Goyal wrote: > On Thu, May 26, 2011 at 01:15:14PM +0200, Reinhard Buendgen wrote: > > Vivek, > > > > I/O is not restricted to disk I/O (it may be network I/O, data sent to > > crtypto cards etc.) and it is not always direct, Device drivers may have > > buffers to which such data is copied. > > > > So it is more than just keys, and it may change over time. > > I do not think hardwiring a filter in makedumpfile is a good idea because > > you would need a new makedumpfile release for every Distribution > > (release). > > Ok, so we are worried about data being in slub/slab caches or driver's > kmalloced buffers etc. > > When do I need access to debuginfo files. I am assuming that makedumpfile > reads them in first kernel sometime and stores relevant info in initramfs. > Otherwise, it is not possible to get to it in second kernel after crash. > The current approach is to re-run the makedumpfile on the crash dump (generated in the second kernel) when we are back into production kernel (1st kernel). > > > > Allowing to configure makedumpfile allows each distribution and each > > platform to provide appropriate filters. > > > > I was thinking that there are very few symbols and these will not change > frequently. makdumpfile is already dependent on some kenrel data strcutres > and symbols for doing filtering. > > But looks like you are planning to filter out lots of symbols. So in that > case agreed that hardcoding is not a good idea. > > Thanks > Vivek > > > Mit freundlichen Gr??en/Best Regards/Cordialement > > > > Reinhard > > > > Dr. Reinhard B?ndgen > > RAS & Crypto Architect for Linux on System z > > Virtualization and Systems Management > > > > Mail:buendgen at de.ibm.com > > Phone: ++49-(0)7031-16-1130 > > Fax: ++49-(0)7031-16-3456 > > > > IBM Deutschland Research & Development GmbH > > Vorsitzender des Aufsichtsrats: Martin Jetter > > Gesch?ftsf?hrung: Dirk Wittkopp > > Sitz der Gesellschaft: B?blingen > > Registergericht: Amtsgericht Stuttgart, HRB 243294 > > > > > > > > > > > > From: Vivek Goyal <vgoyal at redhat.com> > > To: Reinhard Buendgen/Germany/IBM at IBMDE > > Cc: Dave Anderson <anderson at redhat.com>, Ananth N Mavinakayanahalli > > <ananth at in.ibm.com>, kexec at lists.infradead.org, Mahesh J Salgaonkar > > <mahesh at linux.vnet.ibm.com>, "Ken'ichi Ohmichi" > > <oomichi at mxs.nes.nec.co.jp>, V Srivatsa <vsrivatsa at in.ibm.com> > > Date: 25.05.2011 21:53 > > Subject: Re: [PATCH v2 0/8] makedumpfile: makedumpfile enhancement > > to filter out kernel data from vmcore > > > > > > > > On Wed, May 25, 2011 at 10:41:55AM +0200, Reinhard Buendgen wrote: > > > Hi, > > > > > > to answer Vivek questions first: Eventually we want to be able to erase > > > all data that a customer may consider sensitive to her privacy. In > > > addition to encryption key that may be the contents (i.e. payload > > within) > > > of all kinds of I/O buffers. Consider you are running a kvm based > > > hypervisor and want its dump to be analyized while promising your > > > customers whose guests you run on that hypervisor that none of their > > data > > > will be externalized. Or consider your system reads a spreadsheat with > > > bank account or health information. You might not want to send fractions > > > > > of that information sitting in some buffers to a service organization. > > > > So for direct IO, buffer is still in user space and should be filtered > > out when we filter out user space pages using mkdumpfile. For kvm, I am > > assuming that all the pages belong to qemu process and once we are > > filtering out user space pages, any data belonging to guest will go away. > > > > So atleast for above examples it does not sound as if we need symbol > > erase infrastructure. > > > > > > > > to answer Daves concern: there is no intention that crash should ever > > look > > > into the erased structures. In theroy it should not be needed because > > the > > > contents of structures to be deleted should be irrelevant to kernel > > > debugging. > > > > So what are those kernel structures which we are planning to delete and > > are irrelevant to kernel debugging by crash? > > > > I think we are missing something here. If there are only few known > > structures we want to get rid of, lets hardcode it in makedumpfile > > instead of giving user a generic infrastructure. That way we know > > that we are not leaking information at the same time making sure > > that analysis tools are working. > > > > Thanks > > Vivek > > > > _______________________________________________ > kexec mailing list > kexec at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec -- Mahesh J Salgaonkar
