linux-kernel - Re: [PATCH v2] console: Add console=auto option

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:   Fri, 17 Aug 2018 06:36:10 -0400
From:   Prarit Bhargava <prarit@...hat.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     linux-kernel@...r.kernel.org, Mark Salter <msalter@...hat.com>,
        Al Stone <ahs3@...hat.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        x86@...nel.org, Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Kees Cook <keescook@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH v2] console: Add console=auto option

On 08/17/2018 05:38 AM, Sergey Senozhatsky wrote:
> On (08/16/18 13:39), Prarit Bhargava wrote:
>>
>> +		auto	[X86] Enable ACPI SPCR console
> 			^^^^
> 			And arm64?

Hi Sergey, on arm64 if an SPCR is present the early console and console are
initialized by default.  IOW no kernel parameter is necessary to initialize the
console in that case.

> 
> 
> Any chance we can rename param to "spcr" or something more clear?
> To explicitly state what exactly it's going to do. `auto' sounds
> too general and doesn't tell me that much. I'm probably the only
> here who can't see a connection between "auto" and "SPCR", but
> still.

I came up with "auto" because I think it is generic.  I also thought about
"console=fw", or just "console".  If in the future another arch wants to
optionally bring up a firmware or hardware defined console then they could use
auto too.

> 
> One more thing, as far as I can tell, acpi_parse_spcr() can fail
> and return an error. arch_console_setup() hides all errors and
> returns void. Should it return error code?
> 
> 	int arch_console_setup(void)
> 	{
> 		return acpi_parse_spcr(false, true);
> 	}
> 
> Or maybe
> 
> 	void arch_console_setup(void)
> 	{
> 		if (acpi_parse_spcr(false, true))
> 			pr_err(.........);
> 	}
> 
> There can be other consoles in the system, logging an error is not
> such a useless thing.

I can make the second change.  The problem (IIRC) with returning an error in an
setup fn is that the rest of the setup functions will not execute.  I don't want
to fail the setup callbacks because of an incorrect SPCR table.

Like I mentioned to Petr, I'd like to know if you (or anyone else) has strong
feelings about changing the behaviour of earlycon on x86?  I could make it so
that specifying just earlycon would also initialize the console.

P.

> 
> 	-ss
>