[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202305161353.0F771E0@keescook>
Date: Tue, 16 May 2023 13:55:21 -0700
From: Kees Cook <keescook@...omium.org>
To: 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 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.
--
Kees Cook
Powered by blists - more mailing lists