makedumpfile security key filtering with eppic

On Thu, Nov 08, 2012 at 07:08:04PM +0530, Aravinda Prasad wrote:

[..]

Quoted 8 lines

Makefile +0 -0

index d5fc09e..3ac8e63 100644
@@ -55,6 +55,13 @@ LIBS := -llzo2 $(LIBS)
 CFLAGS += -DUSELZO
 endif
 

Makefile LIBS := -llzo2 $(LIBS) · line 59

Quoted 2 lines

Makefile +2 -0

+ifeq ($(EPPIC), on)
+LIBS := -leppic -ltinfo $(LIBS)

So you also pull in libarary "tinfo". Does that 1MB number include this too? What's the total size bloat for makedumpfile once we compile with EPPIC on.

Thanks
Vivek

makedumpfile security key filtering enhancement - Add Eppic language support (formerly known as SIAL) to specify rules to scrub data in a dumpfile. Eppic was previously part of crash source code repository.

The following series of patches enhance the makedumpfile to provide a more powerful way to specify rules and commands to traverse and erase complex data structures in a dump file by integrating Embeddable Pre-Processor and Interpreter for C (eppic).

Eppic is an interpreter that facilitates access to the symbol and type information stored in an executable image or a dump file. Eppic defines a language semantic which is similar to C. Eppic macros can be used to specify rules/commands to erase data in an image file. makedumpfile will interpret the rules/commands provided by eppic macros with the help of eppic library and will suitably erase the required data in a dump file. Eppic provides a lot of language constructs like conditional statements, logical and arithmetic operators, nested loops, functions, etc., to traverse nested lists and trees and conditionally erase data in the dump file, enabling users to literally erase any data in the dump file which is accessible through global symbols.

The series of patches integrates eppic with makdumpfile. These patches require eppic library libeppic.a and eppic_api.h header file. The libeppic.a library can be built from the eppic source code available at the following URL:

http://code.google.com/p/eppic/

TODO:

- Currently, works only for symbols in vmlinux, extend it to module symbols
- Functionality support:
- Implement the following callback functions.
- apialignment
- apigetenum
- apigetdefs
- Other functionalities specified in the code with TODO tag
- Support specifying eppic macros in makedumpfile.conf file
- Update erase info

Changelog from v1 to v2:

- Re-based to v1.5.0
- Introduced EPPIC=on in makefile, and hence eppic is now optional
- Incorporated review comments from Atsushi
- Minor formatting changes

Regards,
Aravinda
---

Aravinda Prasad (7):
Initialize and setup eppic
makedumpfile and eppic interface layer
Eppic call back functions to query a dump image Implement apigetctype call back function Implement apimember and apigetrtype call back functions Extend eppic built-in functions to include memset function Support fully typed symbol access mode

 Makefile          |    7 +
 dwarf_info.c      |  367 +++++++++++++++++++++++++++++++++++++++++++
 dwarf_info.h      |   18 ++
 erase_info.c      |   83 +++++++++-
 erase_info.h      |    5 +
 extension_eppic.c |  451 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 extension_eppic.h |   78 +++++++++
 makedumpfile.c    |    7 +
 makedumpfile.h    |    6 +
 9 files changed, 1018 insertions(+), 4 deletions(-)
 create mode 100644 extension_eppic.c
 create mode 100644 extension_eppic.h

Signature · 7 lines

Aravinda Prasad


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

makedumpfile security key filtering enhancement - Add Eppic language support (formerly known as SIAL) to specify rules to scrub data in a dumpfile. Eppic was previously part of crash source code repository.

The following series of patches enhance the makedumpfile to provide a more powerful way to specify rules and commands to traverse and erase complex data structures in a dump file by integrating Embeddable Pre-Processor and Interpreter for C (eppic).

Eppic is an interpreter that facilitates access to the symbol and type information stored in an executable image or a dump file. Eppic defines a language semantic which is similar to C. Eppic macros can be used to specify rules/commands to erase data in an image file. makedumpfile will interpret the rules/commands provided by eppic macros with the help of eppic library and will suitably erase the required data in a dump file. Eppic provides a lot of language constructs like conditional statements, logical and arithmetic operators, nested loops, functions, etc., to traverse nested lists and trees and conditionally erase data in the dump file, enabling users to literally erase any data in the dump file which is accessible through global symbols.

The series of patches integrates eppic with makdumpfile. These patches require eppic library libeppic.a and eppic_api.h header file. The libeppic.a library can be built from the eppic source code available at the following URL:

http://code.google.com/p/eppic/

TODO:

- Currently, works only for symbols in vmlinux, extend it to module symbols
- Functionality support:
- Implement the following callback functions.
- apialignment
- apigetenum
- apigetdefs
- Other functionalities specified in the code with TODO tag
- Support specifying eppic macros in makedumpfile.conf file
- Update erase info

Changelog from v1 to v2:

- Re-based to v1.5.0
- Introduced EPPIC=on in makefile, and hence eppic is now optional
- Incorporated review comments from Atsushi
- Minor formatting changes

Regards,
Aravinda
---

Aravinda Prasad (7):
Initialize and setup eppic
makedumpfile and eppic interface layer
Eppic call back functions to query a dump image Implement apigetctype call back function Implement apimember and apigetrtype call back functions Extend eppic built-in functions to include memset function Support fully typed symbol access mode

 Makefile          |    7 +
 dwarf_info.c      |  367 +++++++++++++++++++++++++++++++++++++++++++
 dwarf_info.h      |   18 ++
 erase_info.c      |   83 +++++++++-
 erase_info.h      |    5 +
 extension_eppic.c |  451 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 extension_eppic.h |   78 +++++++++
 makedumpfile.c    |    7 +
 makedumpfile.h    |    6 +
 9 files changed, 1018 insertions(+), 4 deletions(-)
 create mode 100644 extension_eppic.c
 create mode 100644 extension_eppic.h

Signature · 7 lines

Aravinda Prasad


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 8 lines · Aravinda Prasad

makedumpfile security key filtering enhancement - Add Eppic language support (formerly known as SIAL) to specify rules to scrub data in a dumpfile. Eppic was previously part of crash source code repository.

The following series of patches enhance the makedumpfile to provide a more powerful way to specify rules and commands to traverse and erase complex data structures in a dump file by integrating Embeddable Pre-Processor and Interpreter for C (eppic).

Hi Aravinda,

Had few questions.

- Which file will contain all the rules?

- What's the memory footprint of libeppic.a? Looks like this will be linked statically with makedumpfile, and how much is the size bloat of makedumpfile.

- Is this supposed to work from kdump initramfs or it is supposed to be used on already saved dump (later during post processing).

Given the fact that it does not reduce the size of core file significantly, I would think that it is better to post process vmcore to wipe out some symbols.

Thanks
Vivek

Quoted 75 lines

Eppic is an interpreter that facilitates access to the symbol and type information stored in an executable image or a dump file. Eppic defines a language semantic which is similar to C. Eppic macros can be used to specify rules/commands to erase data in an image file. makedumpfile will interpret the rules/commands provided by eppic macros with the help of eppic library and will suitably erase the required data in a dump file. Eppic provides a lot of language constructs like conditional statements, logical and arithmetic operators, nested loops, functions, etc., to traverse nested lists and trees and conditionally erase data in the dump file, enabling users to literally erase any data in the dump file which is accessible through global symbols.

The series of patches integrates eppic with makdumpfile. These patches require eppic library libeppic.a and eppic_api.h header file. The libeppic.a library can be built from the eppic source code available at the following URL:

http://code.google.com/p/eppic/

TODO:

- Currently, works only for symbols in vmlinux, extend it to module symbols
- Functionality support:
- Implement the following callback functions.
- apialignment
- apigetenum
- apigetdefs
- Other functionalities specified in the code with TODO tag
- Support specifying eppic macros in makedumpfile.conf file
- Update erase info

Changelog from v1 to v2:

- Re-based to v1.5.0
- Introduced EPPIC=on in makefile, and hence eppic is now optional
- Incorporated review comments from Atsushi
- Minor formatting changes

Regards,
Aravinda
---

Aravinda Prasad (7):
Initialize and setup eppic
makedumpfile and eppic interface layer
Eppic call back functions to query a dump image Implement apigetctype call back function Implement apimember and apigetrtype call back functions Extend eppic built-in functions to include memset function Support fully typed symbol access mode

 Makefile          |    7 +
 dwarf_info.c      |  367 +++++++++++++++++++++++++++++++++++++++++++
 dwarf_info.h      |   18 ++
 erase_info.c      |   83 +++++++++-
 erase_info.h      |    5 +
 extension_eppic.c |  451 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 extension_eppic.h |   78 +++++++++
 makedumpfile.c    |    7 +
 makedumpfile.h    |    6 +
 9 files changed, 1018 insertions(+), 4 deletions(-)
 create mode 100644 extension_eppic.c
 create mode 100644 extension_eppic.h

Signature · 7 lines

Aravinda Prasad


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Hi Vivek,

Quoted 12 lines · Vivek Goyal

Quoted 8 lines · Aravinda Prasad

makedumpfile security key filtering enhancement - Add Eppic language support (formerly known as SIAL) to specify rules to scrub data in a dumpfile. Eppic was previously part of crash source code repository.

The following series of patches enhance the makedumpfile to provide a more powerful way to specify rules and commands to traverse and erase complex data structures in a dump file by integrating Embeddable Pre-Processor and Interpreter for C (eppic).

Hi Aravinda,

Quoted 3 lines

Had few questions.

- Which file will contain all the rules?

As of now rule files will not be provided by makedumpfile. However, writing a rule file is very easy - it is a C program.

Quoted 5 lines

- What's the memory footprint of libeppic.a? Looks like this will be linked statically with makedumpfile, and how much is the size bloat of makedumpfile.

Memory footprint of libeppic.a is around 1MB. Yes, this will be statically linked to makedumpfile. Users should specify EPPIC=on while building the makedumpfile and hence linking libeppic.a is optional

Quoted 4 lines

- Is this supposed to work from kdump initramfs or it is supposed to be used on already saved dump (later during post processing).

For the time being, it is only during post processing.

Quoted 18 lines · Aravinda Prasad

Hi Vivek,

Quoted 14 lines · Vivek Goyal

Quoted 8 lines · Aravinda Prasad

makedumpfile security key filtering enhancement - Add Eppic language support (formerly known as SIAL) to specify rules to scrub data in a dumpfile. Eppic was previously part of crash source code repository.

The following series of patches enhance the makedumpfile to provide a more powerful way to specify rules and commands to traverse and erase complex data structures in a dump file by integrating Embeddable Pre-Processor and Interpreter for C (eppic).

Hi Aravinda,

Had few questions.

Quoted 5 lines

Quoted 1 line

- Which file will contain all the rules?

As of now rule files will not be provided by makedumpfile. However, writing a rule file is very easy - it is a C program.

Can you give some details about how does it work and what's the correlation with makedumpfile.

Quoted 8 lines

Quoted 6 lines

- What's the memory footprint of libeppic.a? Looks like this will be linked statically with makedumpfile, and how much is the size bloat of makedumpfile.

Quoted 3 lines

Memory footprint of libeppic.a is around 1MB. Yes, this will be statically linked to makedumpfile. Users should specify EPPIC=on while building the makedumpfile and hence linking libeppic.a is optional

How would distributions handle it. Will we continue to build makedumpfile without EPPIC=on. Any increase in initramfs size increase is frowned upon in general.

Quoted 7 lines

Quoted 5 lines

- Is this supposed to work from kdump initramfs or it is supposed to be used on already saved dump (later during post processing).

Quoted 1 line

For the time being, it is only during post processing.

Again, how distributions will handle it. If it is being integrated makedumpfile, as opposed to an stand alone utility, that means it makedumpfile needs to link against this library so that somebody can later filter out the symbols. And that means initramfs size bloat too?

Thanks
Vivek

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

struct key in include/linux/key.h holds "authentication token"/"access credential"/"keyring". Suppose these entries should be scrubbed from the dumpfile. Then the keyring_name_hash hash table should be scanned and for each non-empty list, the entire list should be traversed and payload.value (or any other data) in struct key should be cleared.

Now the EPPIC macro looks like this:

int
key()

{
    int i;
    struct list_head *head;
    struct list_head *next, *prev;

    head = (struct list_head *)keyring_name_hash;

    for (i = 0; i < 32; i++)
    {
        next = (struct list_head *) head[i].next;
        prev = (struct list_head *) head[i].prev;

        if (!next)
            continue;

        do
        {
            struct key *mykey, *off = 0;

            mykey = (struct key *)((unsigned long)(next)
                      - ((unsigned long)&(off->type_data)));

            memset((char *)mykey->payload.value, 'X', 0x8);

            next = *(struct list_head **) mykey->type_data.link.next;
        } while (next != prev);
    }
    return 1;
}

The data can be cleared by specifying:
makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore

makedumpfile with the help of eppic will interpret the macro key.c, traverses all the hash chains and erases paylod.value of struct key.

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

- What's the memory footprint of libeppic.a? Looks like this will be linked statically with makedumpfile, and how much is the size bloat of makedumpfile.

Quoted 7 lines

Quoted 3 lines

Memory footprint of libeppic.a is around 1MB. Yes, this will be statically linked to makedumpfile. Users should specify EPPIC=on while building the makedumpfile and hence linking libeppic.a is optional

How would distributions handle it. Will we continue to build makedumpfile without EPPIC=on. Any increase in initramfs size increase is frowned upon in general.

We would like distributions to build makedumpfile with EPPIC=on.

I am not sure, but do you think ~1MB is too much increase to go with?

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

- Is this supposed to work from kdump initramfs or it is supposed to be used on already saved dump (later during post processing).

For the time being, it is only during post processing.

Quoted 5 lines

Again, how distributions will handle it. If it is being integrated makedumpfile, as opposed to an stand alone utility, that means it makedumpfile needs to link against this library so that somebody can later filter out the symbols. And that means initramfs size bloat too?

Yes, makedumpfile needs to be linked against eppic library for filtering data and this will increase makedumpfile size and initramfs size too.

makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore

Quoted 2 lines

Yes, makedumpfile needs to be linked against eppic library for filtering data and this will increase makedumpfile size and initramfs size too.

Just to clarify -- your example indicates that the vmlinux file is required for this facility to work, correct?

Quoted 1 line

makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore

Clearly distros won't be putting the vmlinux file in the initramfs -- that's the whole reasoning behind vmcoreinfo. So the 99% of users that aren't interested in scrubbing will have to pay the penalty of the larger makedumpfile binary.

On Thu, Nov 15, 2012 at 09:27:45AM -0500, Dave Anderson wrote:

[..]

Quoted 8 lines

Quoted 2 lines

Yes, makedumpfile needs to be linked against eppic library for filtering data and this will increase makedumpfile size and initramfs size too.

Just to clarify -- your example indicates that the vmlinux file is required for this facility to work, correct?

Quoted 1 line

makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore

Quoted 4 lines

Clearly distros won't be putting the vmlinux file in the initramfs -- that's the whole reasoning behind vmcoreinfo. So the 99% of users that aren't interested in scrubbing will have to pay the penalty of the larger makedumpfile binary.

That's a good point Dave. We will never put debug compiled vmlinux in initramfs. Following two alternatives come to my mind.

- Either makedumpfile provides some kind of library to parse/read/write dump files and we can write another stand alone utility for scrubbing dump files (say, scrub-vmcore), and it can link against makedumpfile libraries to take advantage of existing code.

- Or, we just identify what we want to scrube and make that code part of makedumpfile. Export relevant data structures from kernel using vmcoreinfo.

I prefer to keep things simple and like second option better.

Thanks
Vivek

Quoted 16 lines · Vivek Goyal

On Thu, Nov 15, 2012 at 09:27:45AM -0500, Dave Anderson wrote:

[..]

Quoted 12 lines

Quoted 2 lines

Yes, makedumpfile needs to be linked against eppic library for filtering data and this will increase makedumpfile size and initramfs size too.

Just to clarify -- your example indicates that the vmlinux file is required for this facility to work, correct?

Quoted 1 line

makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore

Clearly distros won't be putting the vmlinux file in the initramfs -- that's the whole reasoning behind vmcoreinfo. So the 99% of users that aren't interested in scrubbing will have to pay the penalty of the larger makedumpfile binary.

Quoted 2 lines

That's a good point Dave. We will never put debug compiled vmlinux in initramfs. Following two alternatives come to my mind.

As I mentioned, we don't need vmlinux in initramfs as filtering is done during post processing only.

Quoted 20 lines · Aravinda Prasad

Quoted 16 lines · Vivek Goyal

On Thu, Nov 15, 2012 at 09:27:45AM -0500, Dave Anderson wrote:

[..]

Quoted 12 lines

Quoted 2 lines

Yes, makedumpfile needs to be linked against eppic library for filtering data and this will increase makedumpfile size and initramfs size too.

Just to clarify -- your example indicates that the vmlinux file is required for this facility to work, correct?

Quoted 1 line

makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore

Clearly distros won't be putting the vmlinux file in the initramfs -- that's the whole reasoning behind vmcoreinfo. So the 99% of users that aren't interested in scrubbing will have to pay the penalty of the larger makedumpfile binary.

Quoted 6 lines

Quoted 2 lines

That's a good point Dave. We will never put debug compiled vmlinux in initramfs. Following two alternatives come to my mind.

As I mentioned, we don't need vmlinux in initramfs as filtering is done during post processing only.

You are missing the point. The point is that despite the fact that scrubbing will never be done from initramfs, all the users will pay penalty for increased makedumpfile size.

So why not write a separate tool (scrub-vmcore) so that makedumpfile users don't pay the bloated size penatly.

Quoted 11 lines

Quoted 4 lines

As I mentioned, we don't need vmlinux in initramfs as filtering is done during post processing only.

You are missing the point. The point is that despite the fact that scrubbing will never be done from initramfs, all the users will pay penalty for increased makedumpfile size.

So why not write a separate tool (scrub-vmcore) so that makedumpfile users don't pay the bloated size penatly.

As Vivek said, I think it's difficult to persuade almost all distributor to specify EPPIC=on.

So, it seems that separate tool is better way for both user and distributor. If you will make it, I will drop eppic support from v1.5.1 and export core functions from makedumpfile as library for such tools in the future.

Does this meet your purpose, Aravinda ?

Thanks
Atsushi Kumagai

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

On 2012-11-20 15:17, Atsushi Kumagai wrote:

...

Quoted 19 lines

Quoted 11 lines

Quoted 4 lines

As I mentioned, we don't need vmlinux in initramfs as filtering is done during post processing only.

You are missing the point. The point is that despite the fact that scrubbing will never be done from initramfs, all the users will pay penalty for increased makedumpfile size.

So why not write a separate tool (scrub-vmcore) so that makedumpfile users don't pay the bloated size penatly.

As Vivek said, I think it's difficult to persuade almost all distributor to specify EPPIC=on.

So, it seems that separate tool is better way for both user and distributor. If you will make it, I will drop eppic support from v1.5.1 and export core functions from makedumpfile as library for such tools in the future.

Quoted 1 line

Does this meet your purpose, Aravinda ?

Vivek, Atsushi,

How about distributions building two targets one with default makedumpfile and other with EPPIC=on, which can be done by a simple modification to Makefile.

Quoted 31 lines · Aravinda Prasad

On 2012-11-20 15:17, Atsushi Kumagai wrote:

...

Quoted 12 lines

Quoted 11 lines

Quoted 4 lines

As I mentioned, we don't need vmlinux in initramfs as filtering is done during post processing only.

You are missing the point. The point is that despite the fact that scrubbing will never be done from initramfs, all the users will pay penalty for increased makedumpfile size.

So why not write a separate tool (scrub-vmcore) so that makedumpfile users don't pay the bloated size penatly.

Quoted 8 lines

As Vivek said, I think it's difficult to persuade almost all distributor to specify EPPIC=on.

So, it seems that separate tool is better way for both user and distributor. If you will make it, I will drop eppic support from v1.5.1 and export core functions from makedumpfile as library for such tools in the future.

Does this meet your purpose, Aravinda ?

Vivek, Atsushi,

Quoted 3 lines

How about distributions building two targets one with default makedumpfile and other with EPPIC=on, which can be done by a simple modification to Makefile.

That's not a good idea. Generally distributions don't ship multiple binaries with minor differences like that. I think going with a separate tool for doing this kind of filtering is better.

Thanks
Vivek

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Customers who want to filter their dump would certainly prefer a single tool and a single shot to throw away pages, scrub data and then compress, split or send the resulting dump to some target using ssh. This important functionality is lost if scrubbing is not part of makedumpfile and a separate tool is developed which just does scrubbing.

On Thu, Nov 22, 2012 at 10:44:49PM +0530, Aravinda Prasad wrote:

[..]

Quoted 5 lines

Customers who want to filter their dump would certainly prefer a single tool and a single shot to throw away pages, scrub data and then compress, split or send the resulting dump to some target using ssh. This important functionality is lost if scrubbing is not part of makedumpfile and a separate tool is developed which just does scrubbing.

Customers do filtering from initramfs context. It is not practical to save TB of memory and filter it later. And we just concluded that is it not practical to do scrubbing from initramfs due to need of vmlinux.

So doing filtering and doing scrubbing will not happen at the same time practically. So bloating size of makedumpfile does not make sense to me.

Thanks
Vivek

Quoted 9 lines · Vivek Goyal

On Thu, Nov 22, 2012 at 10:44:49PM +0530, Aravinda Prasad wrote:

[..]

Quoted 5 lines

Customers who want to filter their dump would certainly prefer a single tool and a single shot to throw away pages, scrub data and then compress, split or send the resulting dump to some target using ssh. This important functionality is lost if scrubbing is not part of makedumpfile and a separate tool is developed which just does scrubbing.

Quoted 8 lines

Customers do filtering from initramfs context. It is not practical to save TB of memory and filter it later. And we just concluded that is it not practical to do scrubbing from initramfs due to need of vmlinux.

So doing filtering and doing scrubbing will not happen at the same time practically. So bloating size of makedumpfile does not make sense to me.

Another approach is to dynamically load libeppic library - similar way how crash does it. No major changes will be done to makedumpfile code, except the addition of --eppic flag. Upon specifying --eppic flag makedumpfile will dlopen libeppic.so, which will have functionality to scrub the specified data. This will prevent makedumpfile bloat and will not affect the size of initramfs as --eppic is only specified during post processing. The distribution should build and ship libeppic.so and the procedure for building .so will be similar to what we have in crash.

Quoted 23 lines · Aravinda Prasad

Quoted 9 lines · Vivek Goyal

On Thu, Nov 22, 2012 at 10:44:49PM +0530, Aravinda Prasad wrote:

[..]

Quoted 5 lines

Customers who want to filter their dump would certainly prefer a single tool and a single shot to throw away pages, scrub data and then compress, split or send the resulting dump to some target using ssh. This important functionality is lost if scrubbing is not part of makedumpfile and a separate tool is developed which just does scrubbing.

Quoted 8 lines

Customers do filtering from initramfs context. It is not practical to save TB of memory and filter it later. And we just concluded that is it not practical to do scrubbing from initramfs due to need of vmlinux.

So doing filtering and doing scrubbing will not happen at the same time practically. So bloating size of makedumpfile does not make sense to me.

Quoted 8 lines

Another approach is to dynamically load libeppic library - similar way how crash does it. No major changes will be done to makedumpfile code, except the addition of --eppic flag. Upon specifying --eppic flag makedumpfile will dlopen libeppic.so, which will have functionality to scrub the specified data. This will prevent makedumpfile bloat and will not affect the size of initramfs as --eppic is only specified during post processing. The distribution should build and ship libeppic.so and the procedure for building .so will be similar to what we have in crash.

It will still show up in dynamic library dependencing using ldd. We will have to put some hack to exclude the leppic despite the fact that makedumpfile is dependent on it.

In F18, now we use dracut to build kdump initramfs. On command line we specify any extra binaries to be included and makedumpfile is one of those. Dracut will determine all the dependencies and automatically pull these in. So even if we don't use --eppic flag, dracult will pull in eppic shared library anyway.

Thanks
Vivek

Quoted 13 lines

Quoted 8 lines

Another approach is to dynamically load libeppic library - similar way how crash does it. No major changes will be done to makedumpfile code, except the addition of --eppic flag. Upon specifying --eppic flag makedumpfile will dlopen libeppic.so, which will have functionality to scrub the specified data. This will prevent makedumpfile bloat and will not affect the size of initramfs as --eppic is only specified during post processing. The distribution should build and ship libeppic.so and the procedure for building .so will be similar to what we have in crash.

It will still show up in dynamic library dependencing using ldd. We will have to put some hack to exclude the leppic despite the fact that makedumpfile is dependent on it.

Quoted 5 lines

In F18, now we use dracut to build kdump initramfs. On command line we specify any extra binaries to be included and makedumpfile is one of those. Dracut will determine all the dependencies and automatically pull these in. So even if we don't use --eppic flag, dracult will pull in eppic shared library anyway.

I think ldd or dracut will not be able to make out that we are dependent on libeppic.so as we will be using the dlopen("libeppic.so, ...) call to dynamically load. No extra flags will be added to Makefile to specify -leppic while building makedumpfile. Hence, from my understanding, while building kdump initramfs, dracut cannot determine that we are dependent on eppic

On Mon, Dec 03, 2012 at 08:05:54PM +0530, Aravinda Prasad wrote:

[..]

Quoted 20 lines

Quoted 13 lines

Quoted 8 lines

Another approach is to dynamically load libeppic library - similar way how crash does it. No major changes will be done to makedumpfile code, except the addition of --eppic flag. Upon specifying --eppic flag makedumpfile will dlopen libeppic.so, which will have functionality to scrub the specified data. This will prevent makedumpfile bloat and will not affect the size of initramfs as --eppic is only specified during post processing. The distribution should build and ship libeppic.so and the procedure for building .so will be similar to what we have in crash.

It will still show up in dynamic library dependencing using ldd. We will have to put some hack to exclude the leppic despite the fact that makedumpfile is dependent on it.

Quoted 5 lines

In F18, now we use dracut to build kdump initramfs. On command line we specify any extra binaries to be included and makedumpfile is one of those. Dracut will determine all the dependencies and automatically pull these in. So even if we don't use --eppic flag, dracult will pull in eppic shared library anyway.

Quoted 6 lines

I think ldd or dracut will not be able to make out that we are dependent on libeppic.so as we will be using the dlopen("libeppic.so, ...) call to dynamically load. No extra flags will be added to Makefile to specify -leppic while building makedumpfile. Hence, from my understanding, while building kdump initramfs, dracut cannot determine that we are dependent on eppic

Ok, if dracut does not pull in libeppic and does not bloat size of initramfs, I am fine.

Hello Aravinda,

Quoted 30 lines · On Mon, 3 Dec 2012 13:40:01 -0500 Vivek Goyal <[email protected]> wrote:

On Mon, Dec 03, 2012 at 08:05:54PM +0530, Aravinda Prasad wrote:

[..]

Quoted 26 lines

Quoted 13 lines

Quoted 8 lines

Another approach is to dynamically load libeppic library - similar way how crash does it. No major changes will be done to makedumpfile code, except the addition of --eppic flag. Upon specifying --eppic flag makedumpfile will dlopen libeppic.so, which will have functionality to scrub the specified data. This will prevent makedumpfile bloat and will not affect the size of initramfs as --eppic is only specified during post processing. The distribution should build and ship libeppic.so and the procedure for building .so will be similar to what we have in crash.

It will still show up in dynamic library dependencing using ldd. We will have to put some hack to exclude the leppic despite the fact that makedumpfile is dependent on it.

Quoted 5 lines

In F18, now we use dracut to build kdump initramfs. On command line we specify any extra binaries to be included and makedumpfile is one of those. Dracut will determine all the dependencies and automatically pull these in. So even if we don't use --eppic flag, dracult will pull in eppic shared library anyway.

I think ldd or dracut will not be able to make out that we are dependent on libeppic.so as we will be using the dlopen("libeppic.so, ...) call to dynamically load. No extra flags will be added to Makefile to specify -leppic while building makedumpfile. Hence, from my understanding, while building kdump initramfs, dracut cannot determine that we are dependent on eppic

Quoted 2 lines

Ok, if dracut does not pull in libeppic and does not bloat size of initramfs, I am fine.

I agree with this idea too.

However, the release date is closing in, so would you re-send the patch set based on v1.5.1 ? I will accept it as official feature in v1.5.2.

Thanks
Atsushi Kumagai

Another approach is to dynamically load libeppic library - similar way how crash does it. No major changes will be done to makedumpfile code, except the addition of --eppic flag. Upon specifying --eppic flag makedumpfile will dlopen libeppic.so, which will have functionality to scrub the specified data. This will prevent makedumpfile bloat and will not affect the size of initramfs as --eppic is only specified during post processing. The distribution should build and ship libeppic.so and the procedure for building .so will be similar to what we have in crash.

----- Original Message -----

Quoted 10 lines

Another approach is to dynamically load libeppic library - similar way how crash does it. No major changes will be done to makedumpfile code, except the addition of --eppic flag. Upon specifying --eppic flag makedumpfile will dlopen libeppic.so, which will have functionality to scrub the specified data. This will prevent makedumpfile bloat and will not affect the size of initramfs as --eppic is only specified during post processing. The distribution should build and ship libeppic.so and the procedure for building .so will be similar to what we have in crash.

OK, so based upon the most recent discussion here:

Re: [PATCH v2 0/7] makedumpfile security key filtering with eppic
http://lists.infradead.org/pipermail/kexec/2012-December/007452.html

Aravinda states that he will be posting an update for makedumpfile that will dlopen() a new "libeppic.so" shared object that is built with the libeppic.a library.

The upstream eppic git tree contains an "applications/crash" subdirectory that contains the code that creates a crash-utility-specific "eppic.so" file.

Accordingly, this new proposal will also require new source file(s) and a build process to create this new makedumpfile-specific "libeppic.so" shared object.

Arvinda -- will you be proposing an additional "applications/makedumpfile" subdirectory for the upstream eppic git tree that can be used to create the makedumpfile-specific libeppic.so file?

Dave

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

-----Original Message-----
From: Aravinda Prasad [mailto:[email protected]]
Sent: Friday, December 07, 2012 1:05 AM
To: Dave Anderson
Cc: [email protected]; [email protected]; [email protected]; Luc Chouinard; [email protected]; Atsushi Kumagai; Vivek Goyal; [email protected]
Subject: Re: [PATCH v2 0/7] makedumpfile security key filtering with

Quoted 8 lines

----- Original Message -----

Quoted 3 lines

Another approach is to dynamically load libeppic library - similar way how crash does it. No major changes will be done to

Quoted 6 lines

Quoted 6 lines

code, except the addition of --eppic flag. Upon specifying --eppic flag makedumpfile will dlopen libeppic.so, which will have functionality to scrub the specified data. This will prevent makedumpfile bloat and will not affect the size of initramfs as --eppic is only specified during post processing. The distribution should build and ship libeppic.so and the procedure for building

Quoted 7 lines

Quoted 1 line

will be similar to what we have in crash.

OK, so based upon the most recent discussion here:

Re: [PATCH v2 0/7] makedumpfile security key filtering with eppic
http://lists.infradead.org/pipermail/kexec/2012-December/007452.html

Quoted 6 lines

Aravinda states that he will be posting an update for makedumpfile that will dlopen() a new "libeppic.so" shared object that is built with the libeppic.a library.

The upstream eppic git tree contains an "applications/crash" subdirectory that contains the code that creates a

"eppic.so" file.

Quoted 3 lines

Accordingly, this new proposal will also require new source file(s) and a build process to create this new makedumpfile-specific

Quoted 3 lines

shared object.

Arvinda -- will you be proposing an additional

Quoted 2 lines

subdirectory for the upstream eppic git tree that can be used to create the makedumpfile-specific libeppic.so file?

This is what I am planning.

A new extension_eppic.c file will be created under makedumpfile source directory. This file is equivalent to applications/crash/eppic.c in

repository. A new target will be added to the Makefile of makedumpfile

the shared library and to build this shared library libeppic.a would

The makedumpfile specific shared library will be named different - say eppic_mkdumpfile.so to avoid conflict with crash specific libeppic.so.

The reason for including extension_eppic.c under makedumpfile source

because it will be dependent on other functions in makedumpfile code

related calls etc. People modifying those functions should be aware of

callers in extension_eppic.c and if this is included in upstream eppic

be easily overlooked (or may not be aware of its existence).

A flag --eppic will be added to makedumpfile which will dlopen the

library. Few additional helper functions will be added to dwarf_info.c

erase_info.c - the same functions which are in v2 of the patchset.

Quoted 9 lines

Dave

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

--
Regards,
Aravinda

Quoted 4 lines

This is what I am planning.

A new extension_eppic.c file will be created under makedumpfile source directory. This file is equivalent to applications/crash/eppic.c in

upstream eppic

Quoted 1 line

repository. A new target will be added to the Makefile of makedumpfile

to build

Quoted 1 line

the shared library and to build this shared library libeppic.a would

be required.

Quoted 4 lines

The makedumpfile specific shared library will be named different - say eppic_mkdumpfile.so to avoid conflict with crash specific libeppic.so.

The reason for including extension_eppic.c under makedumpfile source

is

Quoted 1 line

because it will be dependent on other functions in makedumpfile code

like dwarf

Quoted 1 line

related calls etc. People modifying those functions should be aware of

the

Quoted 1 line

callers in extension_eppic.c and if this is included in upstream eppic

code, it will

Quoted 1 line

be easily overlooked (or may not be aware of its existence).

The same reasons exists for applications/crash/eppic.c. It only ended up on eppic's git for two reasons. To provide for a complete example of integration into a tool and, because I originally wrote it, I could support it from there without having to send a patch Dave's way.

I expect other applications to own their glue/integration file(s) and only grab libeppic from the git. These applications, will comply to libeppic's APIs and only fixes or new functions will be added to libeppic to support these applications and valid new requirements they may have. Like we did for mkdumpfile.

Same libeppic.so and same libeppic Makefile for all.

On Fri, Dec 07, 2012 at 08:46:33AM -0500, Luc Chouinard wrote:

[..]

Quoted 27 lines

Quoted 4 lines

This is what I am planning.

A new extension_eppic.c file will be created under makedumpfile source directory. This file is equivalent to applications/crash/eppic.c in

upstream eppic

Quoted 1 line

repository. A new target will be added to the Makefile of makedumpfile

to build

Quoted 1 line

the shared library and to build this shared library libeppic.a would

be required.

Quoted 4 lines

The makedumpfile specific shared library will be named different - say eppic_mkdumpfile.so to avoid conflict with crash specific libeppic.so.

The reason for including extension_eppic.c under makedumpfile source

is

Quoted 1 line

because it will be dependent on other functions in makedumpfile code

like dwarf

Quoted 1 line

related calls etc. People modifying those functions should be aware of

the

Quoted 1 line

callers in extension_eppic.c and if this is included in upstream eppic

code, it will

Quoted 1 line

be easily overlooked (or may not be aware of its existence).

The same reasons exists for applications/crash/eppic.c. It only ended up on eppic's git for two reasons. To provide for a complete example of integration into a tool and, because I originally wrote it, I could support it from there without having to send a patch Dave's way.

Quoted 7 lines

I expect other applications to own their glue/integration file(s) and only grab libeppic from the git. These applications, will comply to libeppic's APIs and only fixes or new functions will be added to libeppic to support these applications and valid new requirements they may have. Like we did for mkdumpfile.

Same libeppic.so and same libeppic Makefile for all.

I am lost here. Can somebody explain this thing in layman's terms with simple example. (We have a function foo() in libeppic which makeudmpfile wants to call. Now what?)

Few questions come to my mind.

- What is glue logic and why do we need application specific glue logic to use this library.

- Assuming we need glue logic and assuming it is small enough, will it make sense to build statically build glue logic in application and build actual libeppic as shared object and do dlopen() on it.

Thanks
Vivek

Quoted 38 lines · Vivek Goyal

On Fri, Dec 07, 2012 at 08:46:33AM -0500, Luc Chouinard wrote:

[..]

Quoted 27 lines

Quoted 4 lines

This is what I am planning.

A new extension_eppic.c file will be created under makedumpfile source directory. This file is equivalent to applications/crash/eppic.c in

upstream eppic

Quoted 1 line

repository. A new target will be added to the Makefile of makedumpfile

to build

Quoted 1 line

the shared library and to build this shared library libeppic.a would

be required.

Quoted 4 lines

The makedumpfile specific shared library will be named different - say eppic_mkdumpfile.so to avoid conflict with crash specific libeppic.so.

The reason for including extension_eppic.c under makedumpfile source

is

Quoted 1 line

because it will be dependent on other functions in makedumpfile code

like dwarf

Quoted 1 line

related calls etc. People modifying those functions should be aware of

the

Quoted 1 line

callers in extension_eppic.c and if this is included in upstream eppic

code, it will

Quoted 1 line

be easily overlooked (or may not be aware of its existence).

The same reasons exists for applications/crash/eppic.c. It only ended up on eppic's git for two reasons. To provide for a complete example of integration into a tool and, because I originally wrote it, I could support it from there without having to send a patch Dave's way.

Quoted 7 lines

I expect other applications to own their glue/integration file(s) and only grab libeppic from the git. These applications, will comply to libeppic's APIs and only fixes or new functions will be added to libeppic to support these applications and valid new requirements they may have. Like we did for mkdumpfile.

Same libeppic.so and same libeppic Makefile for all.

Quoted 8 lines

I am lost here. Can somebody explain this thing in layman's terms with simple example. (We have a function foo() in libeppic which makeudmpfile wants to call. Now what?)

Few questions come to my mind.

- What is glue logic and why do we need application specific glue logic to use this library.

Consider this simple eppic macro, which prints the value of the global kernel variable "modules":

smod()

{
	struct list_head *mod;

	mod = (struct list_head *)modules;
	printf("Modules = %p \n", mod);
}

Eppic has logic to interpret this C program, but needs some help in resolving the actual value of "modules" (as well as members of struct list_head) and defines few call-back functions to help it. This generic logic forms libeppic.a. The glue logic implements these call back function to help libeppic.a.

Eg: whenever libeppic.a encounters struct list_head, it calls apimember("list_head") call back function to learn about the details of the members of the structure. Glue logic implement this call-back function and calls libeppic.a calls with information - eppic_member_sname("list_head", "next"), eppic_member_sname("list_head", "prev") etc., inside apimember("list_head").

In crash, the glue logic contains gdb related calls and in makedumpfile it contains dwarf related calls to get the structure members, value of global variables etc. However, libeppic.a does not care what calls we use in the background. It just needs the data. This makes it very generic and powerful.

Now the glue logic along with libeppic.a makes the shared library *.so (named eppic.so for crash, planning to name eppic_makedumpfile.so for makedumpfile), which applications can dlopen().

Hope this helps.

Quoted 1 line

Quoted 4 lines

- Assuming we need glue logic and assuming it is small enough, will it make sense to build statically build glue logic in application and build actual libeppic as shared object and do dlopen() on it.

Glue logic is 450K lines of code (all of them in extension_eppic.c) and

calls lot of eppic library calls, making this glue logic static requires libeppic.a to be statically included, which was our first approach.

Quoted 3 lines

Thanks
Vivek

Quoted 8 lines

Quoted 5 lines

Again, how distributions will handle it. If it is being integrated makedumpfile, as opposed to an stand alone utility, that means it makedumpfile needs to link against this library so that somebody can later filter out the symbols. And that means initramfs size bloat too?

Yes, makedumpfile needs to be linked against eppic library for filtering data and this will increase makedumpfile size and initramfs size too.

Just to clarify -- your example indicates that the vmlinux file is required for this facility to work, correct?

Quoted 2 lines

makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore

Clearly distros won't be putting the vmlinux file in the initramfs -- that's the whole reasoning behind vmcoreinfo. So the 99% of users that aren't interested in scrubbing will have to pay the penalty of the larger makedumpfile binary.

Dave

Quoted 2 lines

Can you give some details about how does it work and what's the correlation with makedumpfile.

struct key in include/linux/key.h holds "authentication token"/"access credential"/"keyring". Suppose these entries should be scrubbed from the dumpfile. Then the keyring_name_hash hash table should be scanned and for each non-empty list, the entire list should be traversed and payload.value (or any other data) in struct key should be cleared.

Now the EPPIC macro looks like this:

int
key()

{
    int i;
    struct list_head *head;
    struct list_head *next, *prev;

    head = (struct list_head *)keyring_name_hash;

    for (i = 0; i < 32; i++)
    {
        next = (struct list_head *) head[i].next;
        prev = (struct list_head *) head[i].prev;

        if (!next)
            continue;

        do
        {
            struct key *mykey, *off = 0;

            mykey = (struct key *)((unsigned long)(next)
                      - ((unsigned long)&(off->type_data)));

            memset((char *)mykey->payload.value, 'X', 0x8);

            next = *(struct list_head **) mykey->type_data.link.next;
        } while (next != prev);
    }
    return 1;
}

The data can be cleared by specifying:
makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore

makedumpfile with the help of eppic will interpret the macro key.c, traverses all the hash chains and erases paylod.value of struct key.

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

- What's the memory footprint of libeppic.a? Looks like this will be linked statically with makedumpfile, and how much is the size bloat of makedumpfile.

Memory footprint of libeppic.a is around 1MB. Yes, this will be statically linked to makedumpfile. Users should specify EPPIC=on while building the makedumpfile and hence linking libeppic.a is optional

On Thu, Nov 15, 2012 at 06:20:44PM +0530, Aravinda Prasad wrote:

[..]

Quoted 44 lines

Quoted 2 lines

Can you give some details about how does it work and what's the correlation with makedumpfile.

struct key in include/linux/key.h holds "authentication token"/"access credential"/"keyring". Suppose these entries should be scrubbed from the dumpfile. Then the keyring_name_hash hash table should be scanned and for each non-empty list, the entire list should be traversed and payload.value (or any other data) in struct key should be cleared.

Now the EPPIC macro looks like this:

int
key()

{
    int i;
    struct list_head *head;
    struct list_head *next, *prev;

    head = (struct list_head *)keyring_name_hash;

    for (i = 0; i < 32; i++)
    {
        next = (struct list_head *) head[i].next;
        prev = (struct list_head *) head[i].prev;

        if (!next)
            continue;

        do
        {
            struct key *mykey, *off = 0;

            mykey = (struct key *)((unsigned long)(next)
                      - ((unsigned long)&(off->type_data)));

            memset((char *)mykey->payload.value, 'X', 0x8);

            next = *(struct list_head **) mykey->type_data.link.next;
        } while (next != prev);
    }
    return 1;
}

Quoted 5 lines

The data can be cleared by specifying:
makedumpfile -c -d 31 -x vmlinux --eppic key.c vmcore filtered_vmcore

makedumpfile with the help of eppic will interpret the macro key.c, traverses all the hash chains and erases paylod.value of struct key.

Ok, are these the only places where key is. Can a copy of it exist in some other buffers? We don't clear these.

Also, if key is the only issue, why not just write this logic in makedumpfile and provide another option, --clear-kernel-keys.

Why to introduce such generic scheme.

[..]

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

- What's the memory footprint of libeppic.a? Looks like this will be linked statically with makedumpfile, and how much is the size bloat of makedumpfile.

Memory footprint of libeppic.a is around 1MB. Yes, this will be statically linked to makedumpfile. Users should specify EPPIC=on while building the makedumpfile and hence linking libeppic.a is optional

1MB bloat is significant given the fact that we reserve only 128MB for kdump kernel. Hence we need to review the benefits of this bloat very carefully.

Thanks
Vivek

Quoted 2 lines

Ok, are these the only places where key is. Can a copy of it exist in some other buffers? We don't clear these.

I don't think a copy exist in other places

Quoted 6 lines

Also, if key is the only issue, why not just write this logic in makedumpfile and provide another option, --clear-kernel-keys.

Why to introduce such generic scheme.

key is not the only issue, it was just an example. There could be other things as well (data in socket buffers, device driver buffers, etc) which customers may consider sensitive/private and are interested in scrubbing.

Also this is an extension to the already existing generic solution implemented in makedumpfile, where rules can be specified using --config option. This extension is built on the existing infrastructure and provides a more flexible and powerful way to specify the data to be scrubbed. For eg, scrubbing the keyring data mentioned in one of my previous mails would not be possible with --config option.

The main intention is to remove confidential information from the dump file, like ssh keys etc., which could be just few bytes, hence, may not reduce the size of the dump significantly.

On Wed, Nov 14, 2012 at 10:36:53PM +0530, Aravinda Prasad wrote:

[..]

Quoted 3 lines

The main intention is to remove confidential information from the dump file, like ssh keys etc., which could be just few bytes, hence, may not reduce the size of the dump significantly.

Where are these ssh keys? Are these in user space memory or kernel memory? How would one know the location of these keys?

Thanks
Vivek

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Hi Vivek,

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Aravinda Prasad

makedumpfile security key filtering enhancement - Add Eppic language support (formerly known as SIAL) to specify rules to scrub data in a dumpfile. Eppic was previously part of crash source code repository.

The following series of patches enhance the makedumpfile to provide a more powerful way to specify rules and commands to traverse and erase complex data structures in a dump file by integrating Embeddable Pre-Processor and Interpreter for C (eppic).

Quoted 5 lines

Hi Aravinda,

Had few questions.

- Which file will contain all the rules?

As of now rule files will not be provided by makedumpfile. However, writing a rule file is very easy - it is a C program.

Quoted 4 lines

- What's the memory footprint of libeppic.a? Looks like this will be linked statically with makedumpfile, and how much is the size bloat of makedumpfile.

Memory footprint of libeppic.a is around 1MB. Yes, this will be statically linked to makedumpfile. Users should specify EPPIC=on while building the makedumpfile and hence linking libeppic.a is optional

Quoted 1 line

Quoted 2 lines

- Is this supposed to work from kdump initramfs or it is supposed to be used on already saved dump (later during post processing).

For the time being, it is only during post processing.

Quoted 4 lines

Given the fact that it does not reduce the size of core file significantly, I would think that it is better to post process vmcore to wipe out some symbols.

The main intention is to remove confidential information from the dump file, like ssh keys etc., which could be just few bytes, hence, may not reduce the size of the dump significantly.

----- Original Message -----

Quoted 39 lines

Hi Vivek,

Quoted 10 lines · Vivek Goyal

Quoted 8 lines · Aravinda Prasad

makedumpfile security key filtering enhancement - Add Eppic language support (formerly known as SIAL) to specify rules to scrub data in a dumpfile. Eppic was previously part of crash source code repository.

The following series of patches enhance the makedumpfile to provide a more powerful way to specify rules and commands to traverse and erase complex data structures in a dump file by integrating Embeddable Pre-Processor and Interpreter for C (eppic).

Quoted 5 lines

Hi Aravinda,

Had few questions.

- Which file will contain all the rules?

As of now rule files will not be provided by makedumpfile. However, writing a rule file is very easy - it is a C program.

Quoted 4 lines

- What's the memory footprint of libeppic.a? Looks like this will be linked statically with makedumpfile, and how much is the size bloat of makedumpfile.

Memory footprint of libeppic.a is around 1MB. Yes, this will be statically linked to makedumpfile. Users should specify EPPIC=on while building the makedumpfile and hence linking libeppic.a is optional

Quoted 3 lines

- Is this supposed to work from kdump initramfs or it is supposed to be used on already saved dump (later during post processing).

Quoted 1 line

For the time being, it is only during post processing.

By post-processing, I understand you to say that the system would be configured to do a full ELF vmcore dump, save it somewhere, and then somebody would do the post-processing at a later time?

Or is it possible to run makedumpfile again on a compressed kdump that was previously created at dump-time?

Quoted 7 lines

Quoted 5 lines

Given the fact that it does not reduce the size of core file significantly, I would think that it is better to post process vmcore to wipe out some symbols.

Quoted 3 lines

The main intention is to remove confidential information from the dump file, like ssh keys etc., which could be just few bytes, hence, may not reduce the size of the dump significantly.

So this would require you to first do a crash analysis on the unfiltered dumpfile, find out what you want to filter, write a script, and then run makedumpfile on the vmcore, correct?

Dave