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: <51244B35.8090006@windriver.com>
Date:	Tue, 19 Feb 2013 20:04:05 -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 05:45 PM, Greg Kroah-Hartman wrote:
>> When vt.init_hide is set, suppress output on newly created consoles
>> until an affirmative switched to that console.  This prevents boot
>> output from displaying (and clobbering splash screens, etc...)
>> without disabling the console entirely.
>
> What's wrong with the 'quiet' option we have?  And you forgot to
> document this.

You're right about docs, obviously.  I'll write something up and send
it tomorrow morning.

But setting "quiet" controls logging.  It won't prevent the console
from doing a buffer clear or mode switch, nor will it prevent
userspace from writing to it, nor will the buffer rewrites due to the
console switches that happen on suspend and resume (which I didn't
know existed) be suppressed.

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.

The idea here (and I'm clearly no domain expert) was to leave the
console enabled and active, but invisible by default.  So nothing
displays, the splash screen stays put, and nothing fights with other
users of the framebuffer.  And it stays that way until something
affirmatively switches to a different VT using chvt or Alt-Fn or
whatever.

To be fair, a lot of this could be managed in userspace with the VT_*
ioctl interface.  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).
This seemed like a much simpler metaphor that still meets the
requirements.

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/