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: Windows password security audit tool. GUI, reports in PDF.

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

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

El jue, 16 mar 2023 a las 14:40, Guenter Roeck (<linux@...ck-us.net>) escribió:
>
> On 3/16/23 03:29, 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).
> >
> > 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).
> >
> > Thank you,
> >
> > (If possible, please CC me in any replies)
> >
> >   [1]: https://lore.kernel.org/lkml/X%2FcDG%2FxCCzSWW2cd@alley/t/
> >
>
> Let me know if/when you find a solution. In ChromeOS we have to carry
> reverts of commit 48021f981308 ("printk: handle blank console arguments
> passed in.") and commit 3cffa06aeef7 ("printk/console: Allow to disable
> console output by using console="" or console=null") to handle the
> same problem (the above mentioned commit didn't work and had odd side
> effects).

The kernel seems to specifically check for "" (empty string) or "null"
and in this case uses the ttynull driver. But apparently we can use
any other invalid string (e.g "invalid") to get the previous behaviour
(no console).

I am still checking if this has other side effects.

Best regards,

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