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

[Aravinda Prasad]

On 2012-11-14 23:23, Vivek Goyal wrote:

> On Wed, Nov 14, 2012 at 10:36:53PM +0530, Aravinda Prasad wrote:
>> Hi Vivek,
>>
>> On 2012-11-14 20:24, Vivek Goyal wrote:
>>
>>> On Thu, Nov 08, 2012 at 07:07:52PM +0530, Aravinda Prasad wrote:
>>>> 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?
>>
>>
>> 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.


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.

> 
> Thanks
> Vivek
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


-- 
Regards,
Aravinda