linux-kernel - Re: early_printk accessing __log

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

Message-Id: <20070718172603.231351ea.akpm@linux-foundation.org>
Date:	Wed, 18 Jul 2007 17:26:03 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Robin Getz <rgetz@...ckfin.uclinux.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: early_printk accessing __log_buf

On Wed, 18 Jul 2007 19:39:46 -0400
Robin Getz <rgetz@...ckfin.uclinux.org> wrote:

> On Wed 18 Jul 2007 18:16, Andrew Morton pondered:
> > 
> > I'd suggest that any interface into here should be via function calls,
> > not via direct access to printk internals: think up some nice
> > copy_me_some_of_the_log_buffer() interface.
> 
> If so - I would still like to put it in:
>  - ifdef CONFIG_EARLY_PRINTK
>  - and define as __init
> 
> so that people don't use it when they shouldn't (when the kernel is up an 
> running).
> 
> Something simple like - early_copy_log_buff(void *dest, size_t n) 
> 
> copies n bytes from log_buf to memory area dest. Returns number of bytes that 
> could not be copied. Can find out how many bytes are in the log_buff by 
> calling with zero size.
> 
> This is not destructive to existing interfaces (log_start and con_start are 
> not updated/used). This should ensure that if booting does work - that normal 
> messages come out the standard method.
> 
> Any other suggestions?
> 

When I was at $EARLIER_EMPLOYER, we had code in there to copy the last
kilobyte-odd of the log buffer into flash when the box oopsed.

So there's one instance proof that something more general would be needed. 
Probably there are others, but they'll mainly be in the consumer/embedded
area, and those sorts of engineers don't read this mailing list much.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/