[RFC] Sanitizing the linux crashdump procedures/handling

[Stefan Bader]

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

Does this sound sensible? What have I missed?

-Stefan

PS: Reminds me of the kerneloops package which was intended to report oopses and
certain warnings from the dmesg (and despite its name not to the kerneloops.org
site anymore), which I think is broken right now. But thats probably another
discussion...


[1] https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-kdump-tool

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130110/eab07875/attachment.pgp>