[RFC] Sanitizing the linux crashdump procedures/handling

[Bouchard Louis]

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

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