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: <2025111214-doily-anyway-b24b@gregkh>
Date: Wed, 12 Nov 2025 06:22:56 -0500
From: Greg KH <gregkh@...uxfoundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
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 Mon, Nov 10, 2025 at 07:57:22PM -0800, H. Peter Anvin wrote:
> Honestly, though, I'm far less interested in what 8250-based hardware does than e.g. USB.

hahahahahahaha {snort}

Hah.  that's a good one.

Oh, you aren't kidding.

Wow, good luck with this.  USB-serial adaptors are all over the place,
some have real uarts in them (and so do buffering in the device, and
line handling in odd ways when powered up), and some are almost just a
straight pipe through to the USB host with control line handling ideas
tacked on to the side as an afterthought, if at all.

There is no standard here, they all work differently, and even work
differently across the same device type with just barely enough hints
for us to determine what is going on.

So don't worry about USB, if you throw that into the mix, all bets are
off and you should NEVER rely on that.

Remeber USB->serial was explicitly rejected by the USB standard group,
only to have it come back in the "side door" through the spec process
when it turned out that Microsoft hated having to write a zillion
different vendor-specific drivers because the vendor provided ones kept
crashing user's machines.  So what we ended up with was "just enough" to
make it through the spec process, and even then line signals are
probably never tested so you can't rely on them.

good luck!

greg "this brought up too many bad memories" k-h