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

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

[Mahesh J Salgaonkar]

Hi All,

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.

---

Mahesh Salgaonkar (6):
      makedumpfile: Add '--config' option to specify filter config file.
      makedumpfile: Apply relocation while loading module debuginfo.
      makedumpfile: Load the module symbol data from vmcore.
      makedumpfile: Introduce routines to get type name from debuginfo.
      makedumpfile: Read and process filter commands from config file.
      makedumpfile: Read and process 'for' command from config file.


 Makefile       |    8 
 filter.conf    |  149 ++++
 filter.conf.8  |  419 +++++++++++
 makedumpfile.8 |   20 +
 makedumpfile.c | 2113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 makedumpfile.h |  152 ++++
 6 files changed, 2782 insertions(+), 79 deletions(-)
 create mode 100644 filter.conf
 create mode 100644 filter.conf.8

-- 
Signature

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

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

[Dave Anderson]

----- Original Message -----
> Hi All,
> 
> 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.

Thanks,
  Dave

 
> ---
> 
> Mahesh Salgaonkar (6):
> makedumpfile: Add '--config' option to specify filter config file.
> makedumpfile: Apply relocation while loading module debuginfo.
> makedumpfile: Load the module symbol data from vmcore.
> makedumpfile: Introduce routines to get type name from debuginfo.
> makedumpfile: Read and process filter commands from config file.
> makedumpfile: Read and process 'for' command from config file.
> 
> 
> Makefile | 8
> filter.conf | 149 ++++
> filter.conf.8 | 419 +++++++++++
> makedumpfile.8 | 20 +
> makedumpfile.c | 2113
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> makedumpfile.h | 152 ++++
> 6 files changed, 2782 insertions(+), 79 deletions(-)
> create mode 100644 filter.conf
> create mode 100644 filter.conf.8
> 
> --
> Signature

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

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

[Ken'ichi Ohmichi]

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. 
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

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

[Mahesh Jagannath Salgaonkar]

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

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

[Ken'ichi Ohmichi]

Hi Mahesh,

On Tue, 15 Mar 2011 10:59:24 +0530
Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> >>
> >> 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.

In my idea, offset_eraseinfo points the *file offset* of the erased
information and size_eraseinfo is the information size.

The erased information would contain *multiple* erased symbol names.
For example, the following is based on your above example.

 	struct S1 {
 		int a;
 		int b;
 		int c;
 	};
 	struct S2 {
 		struct S1 *mystruct1;
 		struct S1 *mystruct2;
 	};
 
 	struct S2 mystruct2;
 
 	#Filter command
 	erase mystruct2.mystruct1.a
 	erase mystruct2.mystruct1.c
 	erase mystruct2.mystruct2.b

	#The erased information
 	erase mystruct2.mystruct1.a 4
 	erase mystruct2.mystruct1.c 4
 	erase mystruct2.mystruct2.b 4


The dumpfile image :

       header             dump data             the erased information
+------------------+-----------------------+-------------------------------+
| ................ | ..................... | erase mystruct2.mystruct1.a 4 |
| offset_eraseinfo | ..................... | erase mystruct2.mystruct1.c 4 |
|   size_eraseinfo | ..................... | erase mystruct2.mystruct2.b 4 |
+------------------+-------------------------------------------------------+
                                           : offset_eraseinfo (offset in dumpfile)
                                            <------ size_eraseinfo ------->
                                            
Thanks
Ken'ichi Ohmichi

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

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

[Mahesh J Salgaonkar]

Hi Ken'inchi,

On Tue, Mar 15, 2011 at 03:12:47PM +0900, Ken'ichi Ohmichi wrote:
> 
> Hi Mahesh,
> 
> In my idea, offset_eraseinfo points the *file offset* of the erased
> information and size_eraseinfo is the information size.
> 
> The erased information would contain *multiple* erased symbol names.
> For example, the following is based on your above example.
> 
>  	struct S1 {
>  		int a;
>  		int b;
>  		int c;
>  	};
>  	struct S2 {
>  		struct S1 *mystruct1;
>  		struct S1 *mystruct2;
>  	};
> 
>  	struct S2 mystruct2;
> 
>  	#Filter command
>  	erase mystruct2.mystruct1.a
>  	erase mystruct2.mystruct1.c
>  	erase mystruct2.mystruct2.b
> 
> 	#The erased information
>  	erase mystruct2.mystruct1.a 4
>  	erase mystruct2.mystruct1.c 4
>  	erase mystruct2.mystruct2.b 4
> 
> 
> The dumpfile image :
> 
>        header             dump data             the erased information
> +------------------+-----------------------+-------------------------------+
> | ................ | ..................... | erase mystruct2.mystruct1.a 4 |
> | offset_eraseinfo | ..................... | erase mystruct2.mystruct1.c 4 |
> |   size_eraseinfo | ..................... | erase mystruct2.mystruct2.b 4 |
> +------------------+-------------------------------------------------------+
>                                            : offset_eraseinfo (offset in dumpfile)
>                                             <------ size_eraseinfo ------->
>                                             

Will work on the cahnge.

Thanks,
-Mahesh.
> Thanks
> Ken'ichi Ohmichi

-- 
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>

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

Re: [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

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

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

[Mahesh Jagannath Salgaonkar]

On 03/11/2011 07:37 PM, Dave Anderson wrote:
> 
> 
> ----- Original Message -----
>> Hi All,
>>
>> 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.

Hmm... I did not think about it. I am thinking of following approach:

- Set a bit in dump_level (DL_FILTER_KERNEL_DATA => 0x800) that will
denote that filtering has been done.
- For compressed kdump file we anyway have dump_level available in kdump
sub header
- For ELF kdump, currently we do not have any way to convey dump_level
info to crash utility (Ken'chi, correct me if I am wrong). How about
introducing an additional ELF note (NT_DUMP_LEVEL) that will include
dump_level info.

Any other suggestions are welcome.

Thanks,
-Mahesh.
> 
> Thanks,
>   Dave
> 
> 
>> ---
>>
>> Mahesh Salgaonkar (6):
>> makedumpfile: Add '--config' option to specify filter config file.
>> makedumpfile: Apply relocation while loading module debuginfo.
>> makedumpfile: Load the module symbol data from vmcore.
>> makedumpfile: Introduce routines to get type name from debuginfo.
>> makedumpfile: Read and process filter commands from config file.
>> makedumpfile: Read and process 'for' command from config file.
>>
>>
>> Makefile | 8
>> filter.conf | 149 ++++
>> filter.conf.8 | 419 +++++++++++
>> makedumpfile.8 | 20 +
>> makedumpfile.c | 2113
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>> makedumpfile.h | 152 ++++
>> 6 files changed, 2782 insertions(+), 79 deletions(-)
>> create mode 100644 filter.conf
>> create mode 100644 filter.conf.8
>>
>> --
>> Signature


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

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

[Ken'ichi Ohmichi]

Hi Mahesh,

On Mon, 14 Mar 2011 11:48:19 +0530
Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> > 
> > 
> > ----- Original Message -----
> >> Hi All,
> >>
> >> 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.
> 
> Hmm... I did not think about it. I am thinking of following approach:
> 
> - Set a bit in dump_level (DL_FILTER_KERNEL_DATA => 0x800) that will
> denote that filtering has been done.
> - For compressed kdump file we anyway have dump_level available in kdump
> sub header
> - For ELF kdump, currently we do not have any way to convey dump_level
> info to crash utility (Ken'chi, correct me if I am wrong). How about
> introducing an additional ELF note (NT_DUMP_LEVEL) that will include
> dump_level info.

On your above approach, a member of support team for analysis cannot
know what symbols are erased.
And he/she will not believe the received dumpfile from a customer site.

I have one question, do you think it is better not to inform support
team of the erased symbols ?
Is also the list of the erased symbols secret ?


Thanks
Ken'ichi Ohmichi

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

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

[Reinhard Buendgen]

[-- Attachment #1.1: Type: text/plain, Size: 4214 bytes --]

Hi,

I do not think the list of erased symbols must be secret. After all we use 
a special value to do most of the erasing. Thus hinting at what was 
erased. 
The intention of this item is certainly not to unduly confuse service. 

this work shall increase the customers confidence that no sensitive data 
may leak through a dump - clearly at the cost with very low probability 
some problems may no longer be analyzed. - But that's all you can do if 
sensitive data is really needed to analyze a problem.

Mit freundlichen Grüßen/Best Regards/Cordialement 

Reinhard

Dr. Reinhard Bündgen 
RAS & Crypto Architect for Linux on System z 
Virtualization and Systems Management 
 
Mail:buendgen@de.ibm.com
Phone: ++49-(0)7031-16-1130
Fax: ++49-(0)7031-16-3456 
 
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp 
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294





From:   "Ken'ichi Ohmichi" <oomichi@mxs.nes.nec.co.jp>
To:     Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com>
Cc:     Dave Anderson <anderson@redhat.com>, V Srivatsa 
<vsrivatsa@in.ibm.com>, kexec@lists.infradead.org, Ananth N 
Mavinakayanahalli <ananth@in.ibm.com>, Reinhard Buendgen/Germany/IBM@IBMDE
Date:   14.03.2011 08:08
Subject:        Re: [PATCH v1 0/6] makedumpfile: makedumpfile enhancement 
to filter out kernel data from vmcore




Hi Mahesh,

On Mon, 14 Mar 2011 11:48:19 +0530
Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> > 
> > 
> > ----- Original Message -----
> >> Hi All,
> >>
> >> 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.
> 
> Hmm... I did not think about it. I am thinking of following approach:
> 
> - Set a bit in dump_level (DL_FILTER_KERNEL_DATA => 0x800) that will
> denote that filtering has been done.
> - For compressed kdump file we anyway have dump_level available in kdump
> sub header
> - For ELF kdump, currently we do not have any way to convey dump_level
> info to crash utility (Ken'chi, correct me if I am wrong). How about
> introducing an additional ELF note (NT_DUMP_LEVEL) that will include
> dump_level info.

On your above approach, a member of support team for analysis cannot
know what symbols are erased.
And he/she will not believe the received dumpfile from a customer site.

I have one question, do you think it is better not to inform support
team of the erased symbols ?
Is also the list of the erased symbols secret ?


Thanks
Ken'ichi Ohmichi


[-- Attachment #1.2: Type: text/html, Size: 6433 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

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

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

[Ken'ichi Ohmichi]

Hi Mahesh,

On Fri, 11 Mar 2011 13:34:32 +0530
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.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.

This patchset is interesting, and I start reviewing.
I haven't reviewed the code yet, and this is a quick review.

* About the filename of configuration.
  Is filter.conf only for makedumpfile command ?
  If so, I feel filter.conf is too generic file name.
  How about makedumpfile.conf ?

  If makedumpfile.conf, it is clear that the file is only for
  makedumpfile, and we will be able to use the file for not only
  erasing secret data but also other purpose.
  (ex: specifying the other options like -d 31 in the file)


Thanks
Ken'ichi Ohmichi

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

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

[Mahesh Jagannath Salgaonkar]

On 03/14/2011 07:25 AM, Ken'ichi Ohmichi wrote:
> 
> Hi Mahesh,
> 
> On Fri, 11 Mar 2011 13:34:32 +0530
> Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.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.
> 
> This patchset is interesting, and I start reviewing.
> I haven't reviewed the code yet, and this is a quick review.
> 
> * About the filename of configuration.
>   Is filter.conf only for makedumpfile command ?
>   If so, I feel filter.conf is too generic file name.
>   How about makedumpfile.conf ?

:-) I initially started with that name. But since it was only for
filtering purpose I went for filter.conf. However, I am ok with the name
makdumpfile.conf
> 
>   If makedumpfile.conf, it is clear that the file is only for
>   makedumpfile, and we will be able to use the file for not only
>   erasing secret data but also other purpose.
>   (ex: specifying the other options like -d 31 in the file)

Agree, Makes sense.
> 
> 
> Thanks
> Ken'ichi Ohmichi


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