linux-kernel - Re: RFC: Serial port DTR/RTS

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: <12e5757c-dc07-40a2-b9c5-57d77dfaffac@zytor.com>
Date: Wed, 12 Nov 2025 11:53:08 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: "Theodore Ts'o" <tytso@....edu>, Maarten Brock <Maarten.Brock@...ls.nl>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Serial port DTR/RTS - O_NRESETDEV

On 2025-11-12 11:39, Greg KH wrote:
> 
>> 3. The only way to determine the type of a tty driver is reading and parsing /proc/tty/drivers; that information is exported neither through ioctl nor sysfs. Exporting *that* through sysfs is probably the easiest of all the improvements.
> 
> The "type" is interesting.  We keep adding new "types" of serial ports
> to the uapi list, and they don't really show up very well to userspace,
> as you say.  Adding this export to sysfs is fine with me, but we should
> make it a string somehow, and not just a random number like the current
> types are listed as, to give people a chance to keep track of this.
> 
> So yes, this too should be done.
> 

Yes, this one is pretty obvious:

>> 4. There isn't a device-independent way to determine if a device is "real" (configured for hardware) or not without opening it and executing one of the termios ioctls like TCGETS (returns -EIO if there isn't anything behind it.) For a UART port it is possible to come up with an educated guess based on the aforementioned sysfs properties (does it have any kind of address associated with it?), but seriously, should stty -a /dev/ttyS0 really glitch RTS# and DTR# even though there is no intent of using the port for communication? 
> 
> Determining "realness" is going to be hard I think (is a usb-serial
> device real or not?  Some are, some are not, but how do we even know?)
> Does a "real" uart mean that the device is real?  How do you define
> that?  What about virtual ones?  Modem chips that do have full line
> discipline support on USB connections?  There's a lot out there to deal
> with here and I think some "fake" ones do pass TCGETS calls just because
> they lie.)
> 

What I mean with "real" is that the device exists at all, unlike e.g.
/dev/ttyS* device nodes which are *only* available for the purpose of binding.

So "bound to a hardware device" is what I mean, not that it is a device with
RS232 drivers on it (which would be impossible to determine, as you very
correctly point out.)

> And addresses are only the "very old" method, many "real" PCI uarts
> don't have them, same for USB ones.
> 
> And changing 'stty -a' is going to be hard, unless you want to use the
> new flag?

That's exactly the idea: use the new open flag.

> But yes, making this more sane is always good, 2 of your things here
> should be pretty simple to knock up if someone wants to.  The others
> might be more difficult just due to backwards compatibility issues.


Indeed. Which is the whole reason for this RFC thread.

	-hpa