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. > > 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 >
