[RFC] Sanitizing the linux crashdump procedures/handling

[Stefan Bader]

On 01/21/2013 02:43 PM, Bouchard Louis wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> Le 10/01/2013 20:54, Stefan Bader a écrit :
>> At UDS we had a session about this [1] and I finally found some
>> time to write up that mail I really wanted to come up with a bit
>> sooner...
>>
>> So right now the kernel-team produces the linux-crashdump
>> meta-package will will pull in kexec-tools and makedumpfile. The
>> kexec-tools package contains some init scripts which will create an
>> apport crash report from the memory dump taken by the kexec-crash
>> run and submits it.
>>
>> For various reasons (see blueprint) we would like to move to use
>> kdump-tools and remove everything related to create dump files from
>> kexec-tools. So that package only provides means to use kexec.
>> Beside other changes this will initially cause the apport crash
>> reports no longer to be produced. But then the general question
>> was: do we really want them to be what they are today? If I have
>> not understood this wrong, we send several megabytes of memory dump
>> out, then on our side pull in even more megabytes of kernel debug
>> packages to look at the panic trace which comes from the dmesg
>> buffer which is only a tiny part of the core file.
>>
>> So one outcome I would like to get from this discussion is to
>> understand better what parts and how exactly those memory dump
>> reports are used. I think apport will ask about sending it but not
>> sure whether is tells you that "by the way this is 20MB of data and
>> may contain sensitive information". I doubt the average user really
>> wants this, let alone business users.
>>
>> My rough idea of how this could look in the end would be: - we
>> remove the dump functionality from kexec-tools - we replace the
>> kexec-tools dependency in linux-crashdump with kdump-tools -
>> kdump-tools would by default produce dumps but no reports (this
>> probably needs some thoughts about where to place those and how to
>> make sure they don't overflow the fs). - we can figure out a way to
>> extract information we need for reports locally and then only
>> report things with as little data as possible (maybe require a
>> setting to enable this).
>>
>
> One option to extract some reporting information could be to extract
> the content of the dmesg in a separate file and include only this in
> the apport report.
>
> makedumpfile has a --dump-dmesg option that can do that in a separate
> pass. While this works well on Debian, it fails on Quantal so maybe
> some more information might be needed in our kernel to achieve this.
>
> Only a few more lines are required in /usr/sbin/kdump-config which is
> part of the kdump-tools package. If this sounds reasonable, I will
> investigate our kernel requirement so this can work on Ubuntu as well.
>
> Any comment ?

After talking to Evan today, this (extracting dmesg) would be the right thing to 
do there. In a second step this would then get piped into something that creates 
some reporting. I will look into extracting the useful pieces of that from 
kerneloops. So if you can look into what is missing in Quantal, that would be 
great. I will let you know how to cause the reports as soon as I got that piece 
ready.

-Stefan
>
> Kind Regards,
>
> ...Louis
>
>
> - --
> Louis Bouchard
> Backline Support Analyst
> Canonical Ltd
> Ubuntu support: http://landscape.canonical.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlD9VA4ACgkQDvqokHrhnCzn3gCg9R5UrxNnI93wjaKvOvMzFKs8
> /qEAoLOkO17o7QX1DvA+wG3U6w3z2W/k
> =7xoP
> -----END PGP SIGNATURE-----
>