lkml.org 
[lkml]   [2016]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2016-10-01 04:43    [W:0.045 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site