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: <5124FFD7.8070708@windriver.com>
Date:	Wed, 20 Feb 2013 08:54:47 -0800
From:	Andy Ross <andy.ross@...driver.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Jiri Slaby <jslaby@...e.cz>, Pavel Machek <pavel@....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/19/2013 08:45 PM, Greg Kroah-Hartman wrote:
 > On Tue, Feb 19, 2013 at 08:04:05PM -0800, Andy Ross wrote:
 > > There's a (sort of) similar commonly-used option, vga=current, which
 > > prevents a mode switch for the special case of VGA/vesa.  But that
 > > doesn't work with the framebuffer console.
 >
 > Why not?  Can't you fix that?

I'd argue that's what this is.  If you were going to design a "shut up
the console" feature from scratch, would you choose to do it in one
particular display driver or would you do it in the device-independent
console code by forcing the already-existing "visible" flag to false?

 > > But the specific application here (Android's surfaceflinger) isn't set
 > > up for that, and it's a non-trivial API (and even doing it "right"
 > > involves racing against other users at startup).
 >
 > How could there be any other users at startup, you "own" the system
 > here, there should not be anyone to race with.

Tell that to the display hardware. :)

Seriously, every Linux box with a display (to first approximation,
obviously I didn't test them all while writing this message) spits
something to the screen between the moment where the bootloader hands
off control and the display driver is initialized.  Most of them
glitch a little at suspend time because of the console switch there.
I just reproduced both of these effects with a Fedora 18 live image.

This fixes almost all of that (vga=current is still required because
some early logging somewhere seems to write to the screen by banging
registers directly and not using the console), and it does it in a way
that works without having to modify existing userspace or (try to)
remove the framebuffer console entirely.

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/