linux-kernel - Re: [PATCH 0/5] tty: add flag to suppress ready signalling on open

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] [day] [month] [year] [list]

Date:   Tue, 8 Dec 2020 10:30:04 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Jiri Slaby <jirislaby@...nel.org>
Cc:     Johan Hovold <johan@...nel.org>,
        Mychaela Falconia <mychaela.falconia@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Mychaela N . Falconia" <falcon@...ecalypso.org>,
        linux-serial@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] tty: add flag to suppress ready signalling on open

On Fri, Dec 04, 2020 at 07:58:53AM +0100, Jiri Slaby wrote:
> On 02. 12. 20, 12:48, Johan Hovold wrote:
> >>> but I question the
> >>> usefulness of doing so, as it is a chicken and egg problem: one needs
> >>> to open the tty device in order to do termios ioctls on it, and if
> >>> that initial open triggers DTR/RTS hardware actions, then the end user
> >>> is still screwed.  If Johan or someone else can see a potential use
> >>> case for manipulating this new flag via termios (as opposed to sysfs
> >>> or USB-ID-based driver quirks), perhaps you could elaborate on it?
> >>
> >> We would need to (ab)use another open flag (e.g. O_DIRECT). I am not
> >> biased to either of solutions.
> > 
> > Forgot to mention that using open-flags would prevent using standard
> > utilities like cat, echo and terminal programs. So for that reason a
> > termios and/or sysfs interface is also preferred.
> 
> Nope, I meant it differently. You set it up once using the special open 
> flag. Like with setserial, one sets I/O port, irqs etc. and then uses 
> standard tools as the port is already set up (marked as NORDY in this
> case).

Ok, but leaving the open flag abuse aside, that would still require a
custom tool to do the setup.

There are also no other examples of such an interface with a "sticky"
open flag affecting later opens. But you probably meant that the open
flag only affects the current open, and then the termios flag is used
to make the setting stick. 

Note that having a udev rule handle this at boot using a sysfs interface
does not require any custom tools at all.

And in theory nothing prevents extending/abusing POSIX with such an open
behaviour later.

Johan