public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com>
To: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Cc: V Srivatsa <vsrivatsa@in.ibm.com>, Reinhard <BUENDGEN@de.ibm.com>,
	Dave Anderson <anderson@redhat.com>,
	kexec@lists.infradead.org,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: Re: [PATCH v1 0/6] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore
Date: Tue, 15 Mar 2011 10:59:24 +0530	[thread overview]
Message-ID: <4D7EF934.3090008@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110314114457.7e252f0d.oomichi@mxs.nes.nec.co.jp>

Hi Ken'chi,

On 03/14/2011 08:14 AM, Ken'ichi Ohmichi wrote:
> 
> Hi Dave, Mahesh,
> 
> On Fri, 11 Mar 2011 09:07:50 -0500 (EST)
> Dave Anderson <anderson@redhat.com> wrote:
>>>
>>> Please find the makedumpfile enhancement patchset that introduces a data
>>> filtering feature which enables makedumpfile to filter out desired kernel
>>> symbol data and it's members from the specified VMCORE file. The data to be
>>> filtered out is poisoned with character 'X' (58 in Hex).
>>>
>>> This feature will be very useful for the customers who wants to erase the
>>> customer sensitive data like security keys and other confidential data, in
>>> DUMPFILE before sending it to support team for analysis.
>>>
>>> This feature introduces a filter config file where, using filter commands,
>>> user can specify desired kernel data symbols and it's members that need to be
>>> filtered out while creating o/p DUMPFILE. The Syntax for filter commands are
>>> provided in the filter.conf(8) man page.
>>>
>>> The first 4 patches prepares the base work for filtering framework.  The last 2
>>> patches implements the generic filtering framework to erase desired kernel
>>> data.
>>>
>>> I have tested these patches on x86_64 and s390x architecture against RHEL6 GA
>>> kernel. The feature supports filtering data from ELF as well as kdump-compressed
>>> formatted dump.
>>>
>>> Please review the patchset and let me know your comments.
>>>
>>> Thanks,
>>> -Mahesh.
>>
>> Hi Mahesh,
>>
>> Is there any notation in the filtered ELF kdump or compressed kdump file
>> that filtering has been done?  Given that there may be potential ramifications
>> in crash utility behavior (or outright failure?), the crash utility should
>> display a warning message early on during invocation.
> 
> That is a good point.
> 
> How about adding new members (like offset_eraseinfo, size_eraseinfo)
> into the sub header in compressed kdump file, and setting version 5
> in the header version (disk_dump_header.header_version) ?
> These members show the erased information like the following:
> 
> struct kdump_sub_header {
>         unsigned long   phys_base;
>         int             dump_level;     /* header_version 1 and later */
>         int             split;          /* header_version 2 and later */
>         unsigned long   start_pfn;      /* header_version 2 and later */
>         unsigned long   end_pfn;        /* header_version 2 and later */
>         off_t           offset_vmcoreinfo;/* header_version 3 and later */
>         unsigned long   size_vmcoreinfo;  /* header_version 3 and later */
>         off_t           offset_note;      /* header_version 4 and later */
>         unsigned long   size_note;        /* header_version 4 and later */
> +       off_t           offset_eraseinfo; /* header_version 5 and later */
> +       unsigned long   size_eraseinfo;   /* header_version 5 and later */
> };
> 
> The erased information contains only effective lines in the
> configuration file.

Do you mean the info would contain symbol name/expression, resolved
symbol/vmalloc addresses and its sizes that got filtered out?

What I mean by symbol expression is, user can ask makedumpfile to erase
a data referred by a member from the symbol variable of structure type.
e.g.
	struct S1 {
		int a;
	};
	struct S2 {
		struct S1 *mystruct1;
	};

	struct S2 mystruct2;

	#Filter command
	erase mystruct2.mystruct1.a

So the erase information in kdump header would contain:

-----------------------------------
Symbol Name: mystruct2.mystruct1.a
Filter Addr: &mystruct2.mystruct1->a
Filter Size: 4	(sizeof type int)
-----------------------------------

For erase commands in loop construct we will have multiple Filter addresses.

Please let me know your comment on the above format.

Hi Dave,

Do you think the above information would be enough for crash utility to
interpret?

Thanks,
-Mahesh.

> In case of ELF kdump file, how about adding a ELF note section
> which also show the erased information ?
> 
> The crash utility will be able to know the name list of the
> erased symbols from the information.
> 
> 
> Thanks
> Ken'ichi Ohmichi
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


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

  reply	other threads:[~2011-03-15  5:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-11  8:04 [PATCH v1 0/6] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore Mahesh J Salgaonkar
2011-03-11 14:07 ` Dave Anderson
2011-03-14  2:44   ` Ken'ichi Ohmichi
2011-03-15  5:29     ` Mahesh Jagannath Salgaonkar [this message]
2011-03-15  6:12       ` Ken'ichi Ohmichi
2011-03-16  5:37         ` Mahesh J Salgaonkar
2011-03-15 14:43       ` Dave Anderson
2011-03-14  6:18   ` Mahesh Jagannath Salgaonkar
2011-03-14  7:05     ` Ken'ichi Ohmichi
2011-03-14  8:51       ` Reinhard Buendgen
2011-03-14  1:55 ` Ken'ichi Ohmichi
2011-03-14  6:26   ` Mahesh Jagannath Salgaonkar

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=4D7EF934.3090008@linux.vnet.ibm.com \
    --to=mahesh@linux.vnet.ibm.com \
    --cc=BUENDGEN@de.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=anderson@redhat.com \
    --cc=kexec@lists.infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox