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

Date:   Tue, 1 Dec 2020 09:40:11 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Mychaela Falconia <mychaela.falconia@...il.com>
Cc:     Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.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 Mon, Nov 30, 2020 at 01:22:07PM -0800, Mychaela Falconia wrote:

> Johan's patch comments say that the new flag can also be brought out
> to termios in the future, similarly to HUPCL, 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?

Depending on the application it may be acceptable to assert the
modem-control lines on first open (e.g. before initialisation). 

A new termios flag allows for a generic interface which could be shared
with other OSes and controlled through stty.

In case that isn't sufficient and you need control over the default port
setting, you can always fall back to the Linux-specific sysfs interface.

> In any case, it would be really awesome if this patch series (with or
> without further modifications) can make it into 5.10 - any chance of
> such happening, or will it have to be pushed out to 5.11?

Let's see, but I don't think this necessarily has to take that long to
get merged.

Johan