linux-kernel - Re: [PATCH v2 0/7] 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]

Message-ID: <X9IcKoofq+2iGZn7@kroah.com>
Date:   Thu, 10 Dec 2020 14:01:30 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Maarten Brock <m.brock@...mierlo.com>
Cc:     Mychaela Falconia <mychaela.falconia@...il.com>,
        Johan Hovold <johan@...nel.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 v2 0/7] tty: add flag to suppress ready signalling on open

On Thu, Dec 10, 2020 at 01:05:15PM +0100, Maarten Brock wrote:
> On 2020-12-10 11:50, Greg Kroah-Hartman wrote:
> > On Thu, Dec 10, 2020 at 11:41:24AM +0100, Maarten Brock wrote:
> > > Hello Mychaela,
> > > 
> > > On 2020-12-09 23:49, Mychaela Falconia wrote:
> > > > Greg K-H wrote:
> > > >
> > > > > I think we need more review for the rest of the series.  This does
> > > > > change the way serial ports work in a non-traditional way (i.e. using
> > > > > sysfs instead of terminal settings).
> > > >
> > > > But the problem is that the current status quo is fundamentally broken
> > > > for those hardware devices in which DTR and/or RTS have been repurposed
> > > > for something other than modem and flow control.  Right now whenever a
> > > > "cold" (never previously opened) serial port is opened for the first
> > > > time, that open action immediately and unstoppably asserts both DTR
> > > > and RTS hardware outputs, without giving userspace any opportunity to
> > > > say "no, please don't do it".  Yes, this behaviour is codified in a
> > > > bunch of standards that ultimately trace back to 1970s Original UNIX,
> > > > but just because it is a standard does not make it right - this
> > > > Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a
> > > > feature.
> > > 
> > > I agree. And an application not configuring the required handshakes,
> > > but
> > > still relying on them is an equal bug.
> > > 
> > > > But if there exist some custom hw devices out there that are in the
> > > > same predicament as my DUART28 adapter, but are different in that they
> > > > are classic old-fashioned RS-232 rather than integrated USB-serial,
> > > > with no place to assign a custom USB ID, *then* we need a non-USB-ID-
> > > > dependent solution such as Johan's sysfs attribute or O_DIRECT.
> > > 
> > > Any device with a classic old-fashioned RS-232 has probably already
> > > solved this in another way or is accepted as not working on Linux.
> > > 
> > > And then there is also the device tree (overlay?) through which a
> > > quirk
> > > like this can be communicated to the kernel driver. Not sure if this
> > > could help for a plug-and-play device like on USB.
> > > 
> > > > > So I want to get a bunch of people
> > > > > to agree that this is ok to do things this way now before taking this
> > > > > new user-visible api.
> > > 
> > > Personally, I would prefer the VID:PID to enforce the quirk and an
> > > O_DIRECT (or other) flag used on open() as general backup plan. To
> > > me a sysfs solution seems illogical.
> > 
> > The "problem" of a vid:pid is that for usb-serial devices, that only
> > describes the device that does the conversion itself, NOT the serial
> > device the converter is plugged into that cares about these types of
> > line-wiggling.
> > 
> > Just like you would not want to classify all devices that met the PCI
> > serial class signature for this type of thing either, there is nothing
> > special about USB here other than it happens to be a common transport
> > for these signals these days.
> > 
> > thanks,
> > 
> > greg k-h
> 
> This is true for a generic USB-UART board or cable, but not for a
> dedicated PCB where both the USB-UART chip and the special connection
> are implemented and which has a dedicated VID:PID different from any
> generic one. In this case the VID:PID describes the whole board.

Companies/devices lie about vid:pid all the time, wait until your
specific vid:pid is repurposed for some other device and then what
happens?  :)

> If the line-wiggling requirement is created behind some sort of
> connector (real RS-232 DB9/DB25 or CMOS pin header or whatever)
> then the problem is the same as for an 8250 on any other bus. For
> this situation I would prefer the O_DIRECT flag on open().

O_DIRECT is an interesting hack, has anyone seen if it violates the
posix rules for us to use it on a character device like this?

thanks,

greg k-h