[RFC] Sanitizing the linux crashdump procedures/handling

[Bouchard Louis]

Hello,

Le 22/01/2013 18:52, Stefan Bader a écrit :
> On 01/21/2013 02:43 PM, Bouchard Louis wrote:
> 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
> 

Good to hear ! Turns out that there is nothing missing in Quantal, but
rather a bug with makedumpfile that doesn't support the change of format
of the kernel log buffer from byte-stream to variable-record format
introduced in the 3.5 kernel.

I'm working on an upstream patch on this change, already fixed in
'crash'. Then I will modify kdump-tools to make use of this functionality.

Kind regards,

..Louis

-- 
Louis Bouchard
Backline Support Analyst
Canonical Ltd
Ubuntu support: http://landscape.canonical.com