[PATCH v1 0/6] makedumpfile: makedumpfile enhancement to filter out kernel data from vmcore

[Dave Anderson]

----- Original Message -----
>
>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 at 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?

To clarify -- I have *no* plans to *interpret* the filter data.  I just
want to know that filtering has been done, and to display a WARNING 
message early on during crash invocation that it has been done.  And
when things subsequently break, at least the user knows why, and I don't
get a bunch of unexplainable bug reports.

So about as far as I would take it in the crash utility would be for the
"help -n" output to display the filter data strings that are appended to
the dumpfile or stored in an ELF note -- much the same way that VMCOREINFO
data can be dumped.

Dave




>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