On Thu, Nov 15, 2012 at 06:20:44PM +0530, Aravinda Prasad wrote:
[..]
> > 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.
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.
[..]
> >>> - 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
