Messages in this thread | | | From | Kees Cook <> | Date | Fri, 30 Sep 2016 19:42:23 -0700 | Subject | Re: [RFC PATCH v1 0/2] printk: Shared kernel logging |
| |
On Fri, Sep 30, 2016 at 6:56 PM, Sean Hudson <darknighte@darknighte.com> wrote: > On 9/29/2016 8:36 PM, Kees Cook wrote: >> On Thu, Sep 29, 2016 at 5:55 PM, Sean Hudson <sean_hudson@mentor.com> >> wrote: >>> This patch set is based on Linus' v4.8-rc8 tag. >>> >>> This debug feature allows the kernel to use an external buffer and >>> control block for kernel log messages. The feature is controlled by >>> an optional command line parameter. The existing buffer and control >>> block can contain existing log messages from previous boot cycles >>> and/or the bootloader. The command line parameter was chosen for >>> flexibility, cross arch portability, and the ability to dynamically >>> enable/disable this feature. The parameter specifies the address of >>> a control block used to replace the default log buffer. Existing >>> bootloader and kernel log messages are kept, in order, inside the >>> new buffer. After a boot that preserves the buffer contents, a >>> bootloader can display both kernel and bootloader log entries from >>> multiple, previous boots. It also allows the kernel to display >>> bootloader log entries along with its own messages. >>> >>> This feature is intended for debug purposes and has no effect >>> unless the command line parameter is specified. Further, it >>> validates the passed control block carefully and if any checks >>> fail, it falls back to the default behaviour. As such, it can be >>> left enabled by default. >>> >>> Memory Reservation >>> >>> This feature expects the bootloader to reserve/preserve the shared >>> buffer memory. This reservation needs to prevent the kernel from >>> overwriting the external log control block and log entries. In my >>> testing, I've used the 'fdt' commands in uboot to dynamically >>> inject reserved memory regions via the DT to the kernel. >> >> Interesting! I wonder if this can be adjusted to incorporate the >> existing console logging feature in the pstore which does a similar >> thing? Though pstore doesn't know about bootloader logs, really, >> it's just storing kernel logs in a ring buffer. Maybe this can >> provide a backend to pstore or something, especially since pstore >> initialization happens "too late" for this to really be very >> sensible. It just seems like it'd be nice to have a single persistent >> console memory region... >> > > I don't know that much about pstore. From your description though, it > sounds feasible to put the two together at some point. How arch > specific is pstore?
The only "weird" part is how to declare the reserved memory range. That depends on either a platform driver or a Device Tree entry, but isn't strictly "arch specific". Otherwise, console writes are preserved in persistent memory as declared by the reservation info. It doesnt, however, _load_ console from such a place.
-Kees
-- Kees Cook Nexus Security
| |