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: <c8f3e485-54c6-99c7-4888-6eef2e174bf6@kernel.org>
Date:   Tue, 1 Dec 2020 08:14:07 +0100
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Mychaela Falconia <mychaela.falconia@...il.com>,
        Johan Hovold <johan@...nel.org>
Cc:     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 30. 11. 20, 22:22, Mychaela Falconia wrote:
> 2) For situations in which the luxury of a custom USB ID is not
> available, e.g., a situation where the device that does not tolerate
> automatic DTR/RTS assertion on open is a physical RS-232 device that
> can be connected to "any" serial port, the new sysfs attribute comes
> to the rescue.
> 
> Johan's patch comments say that the new flag can also be brought out
> to termios in the future, similarly to HUPCL,

The difference to other control flags is that open raises DTR/RTS in any 
case (i.e. including O_NONBLOCK) -- provided baud rate is set (and it is 
for casual serials). That means you cannot open a port to configure it 
(using e.g. setserial) without actually raising the DTR/RTS.

> 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.

thanks,
-- 
js

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ