linux-kernel - Re: [PATCH] console: allow to retain boot console via boot option keep

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:	Thu, 27 Jan 2011 12:47:52 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	fdinitto@...hat.com
Cc:	akpm@...ux-foundation.org, fabbione@...bione.net,
	rdunlap@...otime.net, jmorris@...ei.org, kees.cook@...onical.com,
	mingo@...e.hu, namhyung@...il.com, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] console: allow to retain boot console via boot option
 keep_bootcon

From: "Fabio M. Di Nitto" <fdinitto@...hat.com>
Date: Thu, 27 Jan 2011 15:35:19 +0100

> According to kernel/print.k:
> 
>>         /*
>>          * By unregistering the bootconsoles after we enable the real console
>>          * we get the "console xxx enabled" message on all the consoles -
>>          * boot consoles, real consoles, etc - this is to ensure that end
>>          * users know there might be something in the kernel's log buffer that
>>          * went to the bootconsole (that they do not see on the real console)
>>          */
> 
> but my understanding, and please correct if I am wrong, is that when we
> load or initialize modules such as fbcon (I made this patch debugging a
> crash in atyfb), a console is indeed registered and bootconsole disable,
> while in reality the real console is not there yet (in my case fbcon was
> loaded but not atyfb yet).
> At a later stage, once atyfb is loaded, it registers with fbcon and then
> the console output starts again.

It's not exactly "fbcon", it's the "VT" driver.

That loads, and nothing has attached to VT yet to provide the actual
console hookup.

"fbcon" waits until a usable driver registers before it hooks itself
into the "VT" layer.

So this is why we have this large gap of time with no console output.
It's because VT registers before it actually is able to provide
console output services, and frankly that's a bug. :-)

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