<font size=2 face="sans-serif">Vivek,</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">So it is more than just keys, and it
may change over time.</font>
<br><font size=2 face="sans-serif">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).</font>
<br>
<br><font size=2 face="sans-serif">Allowing to configure makedumpfile allows
each distribution and each platform to provide appropriate filters.</font>
<br><font size=2 face="sans-serif"><br>
</font><font size=2 face="Verdana">Mit freundlichen Grüßen/Best Regards/Cordialement
<br>
</font><font size=5 face="Brush Script"><br>
Reinhard</font>
<p>
<hr noshade>
<table width=100%>
<tr>
<td width=34%><font size=2 face="Verdana"><b>Dr. Reinhard Bündgen </b></font><font size=1 color=#5f5f5f face="Verdana"><br>
RAS & Crypto Architect for Linux on System z <br>
Virtualization and Systems Management </font>
<td width=1%><font size=1 face="Verdana"> </font>
<td width=23%><font size=1 face="Verdana">Mail:</font><a href=mailto:buendgen@de.ibm.com><font size=1 color=blue face="Verdana"><u>buendgen@de.ibm.com</u></font></a><font size=1 face="Verdana"><br>
Phone: ++49-(0)7031-16-1130<br>
Fax: ++49-(0)7031-16-3456 </font>
<td width=1%><font size=1 face="Verdana"> </font>
<td width=38%><font size=1 face="Verdana">IBM Deutschland Research &
Development GmbH</font><font size=1 color=#5f5f5f face="Verdana"><br>
Vorsitzender des Aufsichtsrats: Martin Jetter<br>
Geschäftsführung: Dirk Wittkopp <br>
Sitz der Gesellschaft: Böblingen<br>
Registergericht: Amtsgericht Stuttgart, HRB 243294</font></table>
<br>
<p>
<hr noshade>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Vivek Goyal <vgoyal@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Reinhard Buendgen/Germany/IBM@IBMDE</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">Dave Anderson <anderson@redhat.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>, kexec@lists.infradead.org,
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>, "Ken'ichi Ohmichi"
<oomichi@mxs.nes.nec.co.jp>, V Srivatsa <vsrivatsa@in.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">25.05.2011 21:53</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [PATCH v2
0/8] makedumpfile: makedumpfile enhancement to filter out kernel data from
vmcore</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On Wed, May 25, 2011 at 10:41:55AM +0200, Reinhard
Buendgen wrote:<br>
> Hi,<br>
> <br>
> to answer Vivek questions first: Eventually we want to be able to
erase <br>
> all data that a customer may consider sensitive to her privacy. In
<br>
> addition to encryption key that may be the contents (i.e. payload
within) <br>
> of all kinds of I/O buffers. Consider you are running a kvm based
<br>
> hypervisor and want its dump to be analyized while promising your
<br>
> customers whose guests you run on that hypervisor that none of their
data <br>
> will be externalized. Or consider your system reads a spreadsheat
with <br>
> bank account or health information. You might not want to send fractions
<br>
> of that information sitting in some buffers to a service organization.<br>
<br>
So for direct IO, buffer is still in user space and should be filtered<br>
out when we filter out user space pages using mkdumpfile. For kvm, I am<br>
assuming that all the pages belong to qemu process and once we are<br>
filtering out user space pages, any data belonging to guest will go away.<br>
<br>
So atleast for above examples it does not sound as if we need symbol<br>
erase infrastructure.<br>
<br>
> <br>
> to answer Daves concern: there is no intention that crash should ever
look <br>
> into the erased structures. In theroy it should not be needed because
the <br>
> contents of structures to be deleted should be irrelevant to kernel
<br>
> debugging.<br>
<br>
So what are those kernel structures which we are planning to delete and<br>
are irrelevant to kernel debugging by crash?<br>
<br>
I think we are missing something here. If there are only few known<br>
structures we want to get rid of, lets hardcode it in makedumpfile<br>
instead of giving user a generic infrastructure. That way we know<br>
that we are not leaking information at the same time making sure<br>
that analysis tools are working.<br>
<br>
Thanks<br>
Vivek<br>
</font></tt>
<br>