linux-kernel - Re: Change of behaviour when console=null and ttynull driver is used

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABDcavYLQ63V81z5JiOxZ6hXMj=M+PQpfDLPk6AQynLGwuYTKQ@mail.gmail.com>
Date:   Wed, 22 Mar 2023 09:33:32 +0100
From:   Guillermo Rodriguez Garcia <guille.rodriguez@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     linux-kernel@...r.kernel.org,
        Alejandro Vazquez <avazquez.dev@...il.com>,
        sergey.senozhatsky@...il.com, rostedt@...dmis.org,
        shreyasjoshi15@...il.com, Guenter Roeck <linux@...ck-us.net>
Subject: Re: Change of behaviour when console=null and ttynull driver is used

Hi Petr,

El vie, 17 mar 2023 a las 13:51, Petr Mladek (<pmladek@...e.com>) escribió:
>
> On Thu 2023-03-16 11:29:26, Guillermo Rodriguez Garcia wrote:
> > Hi all,
> >
> > We have several embedded systems where pass console= or console=null
> > in production to disable the console.
> >
> > Later we check for this in user space: in our inittab we check if fd0
> > is "associated with a terminal" (test -t 0); if so, we are in
> > development mode and we open a debug shell; otherwise (console
> > disabled) we just start the application.
> >
> > Recently [1] this behaviour has changed and now if we pass console= or
> > console=null, the new ttynull driver is used. This breaks the check we
> > were doing (test -t 0 always true now).
> >
> > [1]: https://lore.kernel.org/lkml/X%2FcDG%2FxCCzSWW2cd@alley/t/
>
> This is actually exactly the problem that the change tried to solve.
> Some systems failed to boot when there was no console and they tried
> to write something at stdout.

Well, I did not have any problem before this change.

I understand that some systems had a problem (many others didn't, and
setting console= or console=null has been standard practice for a long
time). Since this change in behaviour could (and did) break things in
user space, perhaps it should have been made opt-in...

>
> > Is there a way to get the previous behaviour? If not, is there an easy
> > way for userspace to detect whether the console device is a "real" tty
> > or ttynull (other than trying to parse the kernel boot args, which
> > would be a bit fragile).
>
> A solution would be to check that /proc/consoles has ttynull as the
> only registred console, for example:
>
> grep -q ttynull /proc/consoles && test `cat /proc/consoles | wc -l` -eq 1
>
> Would this work for you, please?

I was trying to avoid something like this as it feels like userspace
now needs to have too much knowledge of what the kernel is doing
internally, however I guess this is the best option.

The suggested check seems to work but now I am seeing a different
(related?) issue: when I try to reboot from the console (using
busybox's reboot command), the system reboots normally if I am using a
"normal" console (e.g. console=ttyXXX), however when using
console=ttynull, the command takes 20-25 seconds to complete. I am not
sure why this would happen; if I understand correctly, for userspace
ttynull is just like a regular tty driver, so why would there be a
difference?

Any ideas?

Thanks,

Guillermo Rodriguez Garcia
guille.rodriguez@...il.com