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]
Date:	Mon, 6 Jul 2015 10:14:34 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	David Cohen <david.a.cohen@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Alan Cox <alan@...ux.intel.com>,
	"Stuart R. Anderson" <stuart.r.anderson@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH] x86: Allow early_printk to use console style param like
 115200n8

When I enable early_printk on a kernel, I cut and paste the console=
input and add to earlyprintk parameter. But I notice recently that
ktest has not been detecting triple faults. The way it detects it, is
by seeing the kernel banner "Linux version .." with a different kernel
version pop up. Then I noticed that early printk was no longer working
on my console, which was why ktest was not seeing it.

I bisected it down and it was added to 4.0 with this commit:

commit ea9e9d802902 ("Specify PCI based UART for earlyprintk")

because it converted the simple_strtoul() that converts the baud number
into a kstrtoul(). The problem with this is, I had as my baud rate,
115200n8 (acceptable for console=ttyS0), but because of the "n8", the
kstrtoul() doesn't parse the baud rate and returns an error, which sets
the baud rate to the default 9600. This explains the garbage on my
screen.

Now, earlyprintk= kernel parameter does not say it accepts that format.
Thus, one answer would simply be me changing my kernel parameters to
remove the "n8" since it isn't parsed anyway. But I wonder if other
people run into this, and it seems strange that the two consoles for
serial accepts different input.

I could also extend this to have earlyprintk do something with that
"n8" or whatever it has and have it match the console parsing (which,
BTW, still uses simple_strtoul(), as I guess it has to).

This patch just makes my old kernel parameter parsing work like it use
to.

Although, simple_strtoull() is considered obsolete, it is the only
standard string parsing function that parses a number that is attached
to text. Ironically, commit ea9e9d802902 also added several calls to
simple_strtoul()!

Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
---
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index a62536a1be88..033a2ca06ea8 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -189,7 +189,7 @@ static __init void early_serial_init(char *s)
 	}
 
 	if (*s) {
-		if (kstrtoul(s, 0, &baud) < 0 || baud == 0)
+		if ((baud = simple_strtoull(s, &e, 0)) == 0 || s == e)
 			baud = DEFAULT_BAUD;
 	}
 

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ