linux-kernel - Re: [PATCH 08/17] tty: New RISC-V SBI console driver

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: <20170713123225.GV6973@jhogan-linux.le.imgtec.org>
Date:   Thu, 13 Jul 2017 13:32:26 +0100
From:   James Hogan <james.hogan@...tec.com>
To:     Michael Ellerman <mpe@...erman.id.au>
CC:     Palmer Dabbelt <palmer@...belt.com>,
        <yamada.masahiro@...ionext.com>, <mmarek@...e.com>,
        <will.deacon@....com>, <peterz@...radead.org>,
        <boqun.feng@...il.com>, <mingo@...hat.com>,
        <daniel.lezcano@...aro.org>, <tglx@...utronix.de>,
        <jason@...edaemon.net>, <marc.zyngier@....com>,
        <gregkh@...uxfoundation.org>, <jslaby@...e.com>,
        <davem@...emloft.net>, <mchehab@...nel.org>,
        <sfr@...b.auug.org.au>, <fweisbec@...il.com>,
        <viro@...iv.linux.org.uk>, <mcgrof@...nel.org>,
        <dledford@...hat.com>, <bart.vanassche@...disk.com>,
        <sstabellini@...nel.org>, <daniel.vetter@...ll.ch>,
        <msalter@...hat.com>, <nicolas.dichtel@...nd.com>,
        <paul.gortmaker@...driver.com>, <linux@...ck-us.net>,
        <heiko.carstens@...ibm.com>, <schwidefsky@...ibm.com>,
        <linux-kernel@...r.kernel.org>, <patches@...ups.riscv.org>,
        <akpm@...ux-foundation.org>, <albert@...ive.com>
Subject: Re: [PATCH 08/17] tty: New RISC-V SBI console driver

On Thu, Jul 13, 2017 at 09:59:53PM +1000, Michael Ellerman wrote:
> Palmer Dabbelt <palmer@...belt.com> writes:
> 
> > On Wed, 12 Jul 2017 04:04:00 PDT (-0700), mpe@...erman.id.au wrote:
> >> Palmer Dabbelt <palmer@...belt.com> writes:
> >>
> >>> On Mon, 10 Jul 2017 23:21:07 PDT (-0700), mpe@...erman.id.au wrote:
> >>>> Palmer Dabbelt <palmer@...belt.com> writes:
> >>>>>
> >>>> ...
> >>>>> +#ifdef CONFIG_EARLY_PRINTK
> >>>>> +static void sbi_console_write(struct console *co, const char *buf,
> >>>>> +			      unsigned int n)
> >>>>> +{
> >>>>> +	int i;
> >>>>> +
> >>>>> +	for (i = 0; i < n; ++i) {
> >>>>> +		if (buf[i] == '\n')
> >>>>> +			sbi_console_putchar('\r');
> >>>>> +		sbi_console_putchar(buf[i]);
> >>>>> +	}
> >>>>> +}
> >>>>> +
> >>>>> +static struct console early_console_dev __initdata = {
> >>>>> +	.name	= "early",
> >>>>> +	.write	= sbi_console_write,
> >>>>> +	.flags	= CON_PRINTBUFFER | CON_BOOT,
> >>>>
> >>>> AFAICS you could add CON_ANYTIME here, which would mean this console
> >>>> would print output before the CPU is online.
> >>>>
> >>>> I think it doesn't currently matter because you call parse_early_param()
> >>>> from setup_arch(), at which point the boot CPU has been marked online.
> >>>>
> >>>> But if this console can actually work earlier then you might be better
> >>>> off just registering it unconditionally very early.
> >>>
> >>> That seems like a good idea.  I'm not familiar with how all this works, but
> >>> from my understanding of this early_initcall() should be sufficient to make
> >>> this work?  The only other driver that sets CON_ANYTIME and supports
> >>> EARLY_PRINTK is hvc_xen, but that installs a header to let init code register
> >>> the console directly.  The early_initcall mechanism seems cleaner if it does
> >>> the right thing.
> >>
> >> Unfortunately early_initcall is not very "early" :)  It's earlier than
> >> all the other initcalls, but it's late compared to most of the arch boot
> >> code.
> >>
> >> The early_param() will work better, ie. register the console earlier
> >> and increase the chance of you getting output from an early crash, than
> >> early_initcall. But it requires you to put earlyprintk on the command line.
> >>
> >> The best option is to just register the console as early as you can, ie.
> >> as soon as it can give you output. So somewhere in your setup_arch(), or
> >> even earlier (I haven't read your boot code).
> >
> > Doing it that way would require either moving the TTY driver into arch code (it
> > was specifically suggested we move it out) or adding a header file to allow
> > setup_arch() to call into the driver (XEN does this, and we're doing it for our
> > timer, but it seems hacky).
> 
> I think it's fairly uncontroversial to have the early console in arch
> code, especially in a case like this where there's no code shared
> between the console and the TTY driver. But maybe someone will prove me
> wrong.
> 
> Doing it the other way is not really hacky IMO, you can just have an
> extern for the early console in one of your asm headers.

For reference both metag and mips do something like this for JTAG based
consoles (with drivers both residing in drivers/tty/):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/metag/kernel/setup.c#n107
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/metag/kernel/setup.c#n234

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/asm/cdmm.h#n98
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/kernel/setup.c#n958

Its not all that pretty but it gets you console output that much
earlier and is a fairly special case, so I think its worth it.

Cheers
James

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)