[PATCH v2 0/8] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore

[Mahesh J Salgaonkar]

Hi Ken'ichi,

On 2011-07-15 14:20:41 Fri, Ken'ichi Ohmichi wrote:
> 
> Hi Mahesh,
> 
> (I'm back to makedumpfile devel for merging this patchset,
>  because Tachibana-san is busy.)

Good to see that you are back.

> 
> Sorry for replying an old mail.
> 
> On Fri, 27 May 2011 12:26:21 +0530
> Mahesh J Salgaonkar <mahesh at linux.vnet.ibm.com> wrote:
> > 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).
> 
> IIUC, there are be 2 dumpfiles on customer site by the above approach.
> The one is with privacy/secret data, and another is without.

Correct.

> 
> If correct, I like this approach because a customer can have two options
> when the crash utility cannot read a dumpfile without privacy/secret data
> on support site.

The crash utility would just display a warning message early on during
invocation. Most of the time crash tool will be able to read/analyze the
dump unless someone scrubs out the data on which crash utility is dependant
on. And as I mentioned previously, this is intended just as a security filter
and not to be used as detrimental to crash's analysis of the dump.

> 
> First option:
>   For digging a problem, a customer sends a dumpfile with privacy/secret
>   data to support site.
> 
> Second option:
>   For protecting privacy/secret data, a customer gives up digging a problem.
> 
> 
> Thanks
> Ken'ichi Ohmichi

Thanks,
-Mahesh.

> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

-- 
Mahesh J Salgaonkar