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