| 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
| ||
|
Message-ID: <200906290703.21539.rgetz@blackfin.uclinux.org>
Date: Mon, 29 Jun 2009 07:03:21 -0400
From: Robin Getz <rgetz@...ckfin.uclinux.org>
To: "Ingo Molnar" <mingo@...e.hu>
CC: linux-kernel@...r.kernel.org
Subject: RFC - printk handling more than one CON_BOOT
Today, register_console() assumes the following usage (with respect to boot
consoles/early_printk).
The first console to register with register_console() with a flags set to
CON_BOOT is the one and only bootconsole.
If another register_console() is called with an additional CON_BOOT, today it
is silently rejected.
As soon as a console without the CON_BOOT set calls register_console(), the
one and only bootconsole is automatically unregistered.
Once there is a "standard" console - register_console() will silently reject
any consoles with it's CON_BOOT, set.
This changeset allows multiple boot consoles, and changes the functionality
to, be mostly the same as the above.
Any number of bootconsoles can be registered.
A "real" console will unregister all the bootconsoles.
Once a "real" console is registered, no more bootconsoles can be added.
Thoughts?
The use case is to have a console buffer which goes to serial, and a console
buffer which goes to a fixed memory buffer at the same time. (serial is what
most people use, but if serial is hosed for some reason, having things in
a buffer (which gets printed out by the bootloader) is the only way to
tell what is going on).
If you don't object I will send a properly formatted patch...
-------------
Index: kernel/printk.c
===================================================================
--- kernel/printk.c (revision 6860)
+++ kernel/printk.c (working copy)
@@ -1126,9 +1126,24 @@
unsigned long flags;
struct console *bootconsole = NULL;
+ /* before we register a new CON_BOOT console, make sure we don't
+ * already have a valid console
+ */
if (console_drivers) {
- if (console->flags & CON_BOOT)
- return;
+ if (console->flags & CON_BOOT) {
+ for (bootconsole = console_drivers;
+ bootconsole != NULL;
+ bootconsole = bootconsole->next) {
+ if (!(bootconsole->flags & CON_BOOT))
+ break;
+ }
+ if ((console->flags & CON_BOOT) &&
+ !(bootconsole->flags & CON_BOOT))
+ return;
+ if (!(bootconsole->flags & CON_BOOT))
+ bootconsole = NULL;
+ }
+
if (console_drivers->flags & CON_BOOT)
bootconsole = console_drivers;
}
@@ -1195,15 +1210,32 @@
if (!(console->flags & CON_ENABLED))
return;
- if (bootconsole && (console->flags & CON_CONSDEV)) {
- printk(KERN_INFO "console handover: boot [%s%d] -> real [%s%d]\n",
- bootconsole->name, bootconsole->index,
- console->name, console->index);
- unregister_console(bootconsole);
+ if (bootconsole && (console->flags & CON_CONSDEV) &&
+ !(console->flags & CON_BOOT)) {
+ /* we need to iterate through twice, to make sure we print
+ * everything out, before we unregister the console(s)
+ */
+ printk(KERN_INFO "console handover: ");
+ for (bootconsole = console_drivers; bootconsole != NULL;
+ bootconsole = bootconsole->next) {
+ if (bootconsole->flags & CON_BOOT)
+ printk("boot [%s%d] ", bootconsole->name,
+ bootconsole->index);
+ }
+ printk(" -> real [%s%d]\n", console->name, console->index);
+ for (bootconsole = console_drivers; bootconsole != NULL;
+ bootconsole = bootconsole->next) {
+ if (bootconsole->flags & CON_BOOT)
+ unregister_console(bootconsole);
+ }
console->flags &= ~CON_PRINTBUFFER;
} else {
- printk(KERN_INFO "console [%s%d] enabled\n",
- console->name, console->index);
+ if (console->flags & CON_BOOT)
+ printk(KERN_INFO "bootconsole [%s%d] enabled\n",
+ console->name, console->index);
+ else
+ printk(KERN_INFO "console [%s%d] enabled\n",
+ console->name, console->index);
}
/*
--
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/
Powered by blists - more mailing lists