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:  <469ECBD1.8080404@yahoo.ca>
Date:	Wed, 18 Jul 2007 22:26:25 -0400
From:	Stephane Couture <muscou@...oo.ca>
To:	linux-kernel@...r.kernel.org
Cc:	Robin Getz <rgetz@...ckfin.uclinux.org>,
	linux-kernel@...r.kernel.org
Subject:  Re: early_printk accessing __log_buf

Andrew Morton wrote:
> 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.
> 

We log everything to SRAM so having the option to select the buffer 
destination address would be nice.  My crude way of doing it:

--- 2.6.21/kernel/printk.c@@/main/1      2007-04-27 05:34:35.000000000
-0400
+++ 2.6.21/kernel/printk.c@@/main/2      2007-05-01 02:27:18.000000000 -0400
@@ -94,7 +94,12 @@
   */
  static unsigned long log_start;        /* Index into log_buf: next 
char to be read by syslog() */
  static unsigned long con_start;        /* Index into log_buf: next 
char to be sent to consoles */
+#ifndef CONFIG_LOG_BUF_ALTERNATE_ADRS
  static unsigned long log_end;  /* Index into log_buf: 
most-recently-written-char + 1 */
+#else
+extern int alt_log_end_adrs;
+#define log_end (*(unsigned long*)alt_log_end_adrs)
+#endif

  /*
   *     Array of consoles built from command line options (console=)
@@ -117,8 +122,14 @@

  #ifdef CONFIG_PRINTK

+#ifndef CONFIG_LOG_BUF_ALTERNATE_ADRS
  static char __log_buf[__LOG_BUF_LEN];
  static char *log_buf = __log_buf;
+#else
+extern int alt_log_buf_adrs;
+#define __log_buf ((unsigned char*)alt_log_buf_adrs)
+#define log_buf ((unsigned char*)alt_log_buf_adrs)
+#endif
  static int log_buf_len = __LOG_BUF_LEN;
  static unsigned long logged_chars; /* Number of chars produced since 
last read+clear operation */


-
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/