From: Vivek Goyal <vgoyal@redhat.com>
To: Reinhard Buendgen <BUENDGEN@de.ibm.com>
Cc: V Srivatsa <vsrivatsa@in.ibm.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>,
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>,
kexec@lists.infradead.org, Dave Anderson <anderson@redhat.com>
Subject: Re: [PATCH v2 0/8] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore
Date: Wed, 25 May 2011 15:53:21 -0400 [thread overview]
Message-ID: <20110525195321.GD6724@redhat.com> (raw)
In-Reply-To: <OF341326C7.0D81F89A-ONC125789B.002DB6ED-C125789B.002FC7A0@de.ibm.com>
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2011-05-25 19:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-17 19:59 [PATCH v2 0/8] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore Mahesh J Salgaonkar
2011-05-18 0:49 ` Ken'ichi Ohmichi
2011-05-24 20:35 ` Vivek Goyal
2011-05-24 20:47 ` Dave Anderson
[not found] ` <OF341326C7.0D81F89A-ONC125789B.002DB6ED-C125789B.002FC7A0@de.ibm.com>
2011-05-25 19:53 ` Vivek Goyal [this message]
2011-05-26 11:15 ` Reinhard Buendgen
2011-05-26 13:39 ` Vivek Goyal
2011-05-27 6:56 ` Mahesh J Salgaonkar
2011-07-15 5:20 ` Ken'ichi Ohmichi
2011-07-15 7:10 ` Mahesh J Salgaonkar
2011-07-15 7:38 ` Ken'ichi Ohmichi
2011-05-25 7:44 ` Mahesh J Salgaonkar
2011-05-25 18:55 ` Vivek Goyal
2011-05-25 19:16 ` Dave Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110525195321.GD6724@redhat.com \
--to=vgoyal@redhat.com \
--cc=BUENDGEN@de.ibm.com \
--cc=ananth@in.ibm.com \
--cc=anderson@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=mahesh@linux.vnet.ibm.com \
--cc=oomichi@mxs.nes.nec.co.jp \
--cc=vsrivatsa@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.