linux-kernel - Re: [PATCH 1/23] Make register values available to panic notifiers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4BC62CFB.2060003@cisco.com>
Date:	Wed, 14 Apr 2010 17:00:43 -0400
From:	David VomLehn <dvomlehn@...co.com>
To:	David VomLehn <dvomlehn@...co.com>, linux-arch@...r.kernel.org,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/23] Make register values available to panic notifiers

Russell King wrote:
> On Sun, Apr 11, 2010 at 11:06:09PM -0700, David VomLehn wrote:
>   
>> This patch makes panic() and die() registers available to, for example,
>> panic notifier functions.  Panic notifier functions are quite useful
>> for recording crash information, but they don't get passed the register
>> values. This makes it hard to print register contents, do stack
>> backtraces, etc. The changes in this patch save the register state when
>> panic() is called and introduce a function for die() to call that allows
>> it to pass in the registers it was passed.
>>     
>
> Can you explain why you want this?
>
> I'm wondering about the value of saving the registers; normally when a panic
> occurs, it's because of a well defined reason, and not because something
> went wrong in some CPU register; to put it another way, a panic() is a
> more controlled exception than a BUG() or a bad pointer dereference.
>   
More context probably helps, starting with noting that the platform is 
an embedded
one. (I'm at the Eembedded Linux Conference, which is why my reply is so 
tardy).
In embedded systems we frequently (probably?) don't have the resources 
to create or
store a crash dump. A very common approach is to record a subset of the 
system
state that is likely to help diagnose the failure. The state information 
is then stored\
on the system or sent upstream to some network-connected node. When I 
gave a talk
about this at the ELC, I polled the audience and got at least half a 
dozen other
companies using the same approach. This is the first set of patches to 
allow this
common embedded community requirement to be met. My expectation that 
register
values will be wanted by everyone doing this kind of targeted state 
reporting.

I should also note that I regard this is more the beginning of a 
conversation on how
to diagnose kernel (and, possibly, application) failures on crash 
dump-less systems.
I would expect to see some number of patches, some of which will 
ultimately be
dropped in favor of other approaches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/