Re: [RFC PATCH v1 0/2] printk: Shared kernel logging

[Kees Cook]

On Fri, Sep 30, 2016 at 6:56 PM, Sean Hudson <darknighte@xxxxxxxxxxxxxx> wrote:
> On 9/29/2016 8:36 PM, Kees Cook wrote:
>> On Thu, Sep 29, 2016 at 5:55 PM, Sean Hudson <sean_hudson@xxxxxxxxxx>
>> 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