linux-kernel - Re: RFC design of device coredump collection on panic in Pstore

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] [day] [month] [year] [list]

Message-ID: <af478340-6f3f-48d7-b88a-7dd3fa7b8e51@linaro.org>
Date: Tue, 21 Jan 2025 15:12:39 +0200
From: Eugen Hristev <eugen.hristev@...aro.org>
To: Kees Cook <keescook@...omium.org>, Mukesh Ojha <quic_mojha@...cinc.com>
Cc: gregkh@...uxfoundation.org, tony.luck@...el.com, gpiccoli@...lia.com,
 johannes@...solutions.net, rafael@...nel.org,
 linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
 quic_shashim@...cinc.com, quic_pkondeti@...cinc.com
Subject: Re: RFC design of device coredump collection on panic in Pstore

On 5/16/23 23:55, Kees Cook wrote:
> On Mon, May 08, 2023 at 09:21:00PM +0530, Mukesh Ojha wrote:
>> 1. Device_coredump allocates some configurable contigous memory that can be controlled
>>    via CONFIG or bootargs and later registers for panic notifiers.
>> 2. Notifier gets added.
>> 3. Pstore adds device_coredump as its front-end via dumper registration similar
>>    to kmsg being dump today.
>> 4. Successful registration of dumper.
>> 5. A device driver(A-Z) can register their buffer to be dumped as part of panic.
>> 6. buffer gets added to the dump list.
>> 7. Panic occurs.
>> 8. iterate over registered drivers and copy their dump list to its own memory and if
>>    it crosses device core dump memory log an error stop iterating.
>> 9. Similar to devcore_dump() inline with kmsg_dump()
>> 10.Copy the content to pstore region and this could be elf or raw binary that can be
>>    discussed.
> 
> Yeah, I think having something like the panic dump handlers for
> driver-specific data sounds like a fine idea (as long as we have actual
> users of such an interface).
> 
> I think it would be easy to add another front-end to pstore (via the
> enums, etc), and expose it via a new template filename in the pstorefs.
> 

Hello Kees,

Currently I am working to get a similar design on Pstore as described by
Mukesh, with some differences.
I want to be able to register memory areas into Pstore, not by doing a
copy, just by registering via a new API (as a frontend, area pointer and
size). Further, these memory areas would be registered to a new type of
zone inside pstore/zone called directly mapped zone, and then registered
to any kind of backend that would support it. The backend would then
decide what to do with the memory area, have it ready in a list for a
panic case, hangup, or hardware fault; or something else.
This implementation would avoid memory copy operations, memory
reservations, and dependency to a panic handler being run. It would work
in multiple scenarios, not just when the kernel is being able to run a
panic handler.
Further, the data can be extracted either by JTAG, firmware, remote
processor or any other solution, including dedicated storage, shared
memory. One could then use it to construct a coredump or specific dump
information.
Having different memory areas being registered has the advantage of
being flexible and small, ranging from nothing to a full kernel memory
range.

What do you think about this approach ? Do you see it working like this ?

Thank you for your suggestions,
Eugen