Re: [PATCH v2 0/7] makedumpfile security key filtering with eppic

[Aravinda Prasad <aravinda@linux.vnet.ibm.com>]

On 2012-11-15 21:19, Vivek Goyal wrote:

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


I don't think a copy exist in other places

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


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


-- 
Regards,
Aravinda


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