linux-kernel - Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

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: <51254959.1020309@windriver.com>
Date:	Wed, 20 Feb 2013 14:08:25 -0800
From:	Andy Ross <andy.ross@...driver.com>
To:	Pavel Machek <pavel@....cz>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Jiri Slaby <jslaby@...e.cz>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Len Brown <len.brown@...el.com>, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org
Subject: Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

On 02/20/2013 12:57 PM, Pavel Machek wrote:
> I'm sure something creative can be done with fake init that shuts
> the console up then execs previous init. No need to add more kernel
> knobs, I'd say.

Fair enough, but some last words:

That's argument is the "it's about logging" hypothesis again.  Even if
it were possible to completely shut up console output (something
that's awfully hard in the general case when running on PC hardware,
and IMHO from a developer's perspective not even a good thing), that's
not the whole problem.  The framebuffer console initialization does a
buffer clear and mode set, and that clobbers anything the bootloader
might have left on the screen prematurely, before userspace is ready
to throw up its own splash.  Splash screens may be a silly
requirement, but they're still a requirement.

And the suspend console problem is likewise at work: ideally you'd
like to know, for example, that the panel backlight is off before
suspending.  But what happens in practice is that the kernel does a VT
switch to/from console 63 and the backlight wakes up (I'm not going to
pretend I have this bit completely figured out, but the problem is/was
real and this patch fixed it by suppressing the console visibility).

Now, the point that an in-kernel console is "going away" and thus not
worth augmenting with new APIs is valid.  And this is a small patch
that's unlikely to be difficult to maintain in a custom tree.  And as
we all agree there are other mechanisms that can be used here (even if
AFAICT they don't completely solve the problem), and indeed I'd love
to get surfaceflinger working with VT_ACTIVATE et. al. if I get a
chance.  So I'm not going to cry if this isn't worth mainline.

But at the same time: all that other stuff doesn't quite meet the
requirements (which in this case are basically "nothing happens
visually between bootloader handoff and the surfaceflinger splash").
What you get with that is something like what you get with desktop
distros: you "mostly" never see the console, except when you do.

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