linux-kernel - Re: [PATCH v8 0/3] x86/earlyprintk: setup serial earlyprintk as early as possible

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: <20150529165536.GD31469@pd.tnic>
Date:	Fri, 29 May 2015 18:55:36 +0200
From:	Borislav Petkov <bp@...e.de>
To:	Alexander Kuleshov <kuleshovmail@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mark Rustad <mark.d.rustad@...el.com>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH v8 0/3] x86/earlyprintk: setup serial earlyprintk as
 early as possible

On Thu, May 28, 2015 at 02:01:12PM +0600, Alexander Kuleshov wrote:
> 2015-05-27 18:51 GMT+06:00 Borislav Petkov <bp@...e.de>:
> > Now, have you tested this on real hardware? Because your 0/n message
> > said "qemu" but I don't think that's sufficient. If we're going to
> > enable early_printk this early, we'd need it working on real hardware
> > too.
> >
> > For that I'd suggest adding a 4th, test patch which issues a couple of
> > numbered early_printk() lines which we could run on a bunch of machines
> > to see whether it actually works.
> 
> Thank you for suggestions. But how to do it? The patch already contains:
> 
> if (console_loglevel >= CONSOLE_LOGLEVEL_DEBUG)
>       early_printk("Early printk is initialized\n");

You can boot with "ignore_loglevel" to see that message. Provided
ignore_loglevel is even parsed that early.

> But I've just noticesed that it does not print anything, because
> console_loglevel can be CONSOLE_LOGLEVEL_DEBUG
> only after parse_early_params too :) How to better be with it? To remove
> if clause and just leave early_printk or something else?
> 
> Or you meant something else about patch for testing?

Yes, I meant a testing patch which is used only for testing and which
issues a bunch of early_printk() calls.

But, before you do that, your patchset has more problems. Booting in
qemu+kvm gives this:

early console in setup code
early console in decompress_kernel

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[    0.000000] bootconsole [earlyser0] enabled
[    0.000000] ERROR: earlyprintk= earlyser already used
	       ^^^^^^

[    0.000000] Linux version 4.1.0-rc5+ (boris@pd) (gcc version 4.9.2 (Debian 4.9.2-10) ) #3 SMP PREEMPT Fri May 29 18:41:59 CEST 2015
[    0.000000] Command line: root=/dev/sda1 debug ignore_loglevel log_buf_len=16M earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0

...

[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [tty0] enabled
[    0.000000] bootconsole [earlyser0] disabled
[    0.000000] bootconsole [earlyser0] enabled
[    0.000000] ERROR: earlyprintk= earlyser already used

...

[    0.000000]  per task-struct memory footprint: 2688 bytes
[    0.000000] WARNING: lockdep init error! lock-(console_sem).lock was acquiredbefore lockdep_init
[    0.000000] Call stack leading to lockdep invocation was:
[    0.000000]  [<ffffffff81013f0f>] save_stack_trace+0x2f/0x50
[    0.000000]  [<ffffffff810a364c>] __lock_acquire+0xa2c/0xf00
[    0.000000]  [<ffffffff810a440b>] lock_acquire+0xdb/0x2b0
[    0.000000]  [<ffffffff81676b33>] _raw_spin_lock_irqsave+0x53/0x90
[    0.000000]  [<ffffffff8109b146>] down+0x16/0x50
[    0.000000]  [<ffffffff810b4d49>] console_lock+0x19/0x60
[    0.000000]  [<ffffffff810b78e6>] register_console+0x116/0x350
[    0.000000]  [<ffffffff81c36162>] setup_early_printk+0x165/0x467
[    0.000000]  [<ffffffff81c364ba>] setup_early_serial_console+0x56/0x58
[    0.000000]  [<ffffffff81c24565>] x86_64_start_kernel+0xce/0x110
[    0.000000]  [<ffffffffffffffff>] 0xffffffffffffffff
[    0.000000] ------------------------

This last one shows that you'd need to look into lockdep first. It also
shows that early boot order is pretty fragile so one has to be very
careful when changing stuff there.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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/