linux-kernel - Re: [PATCH 0/3] serial: Fix support for UPF_SPD

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:   Thu, 7 Jul 2022 10:48:40 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        Johan Hovold <johan@...nel.org>,
        Marek Behún <kabel@...nel.org>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] serial: Fix support for UPF_SPD_* flags

On Friday 22 April 2022 16:28:06 Greg Kroah-Hartman wrote:
> On Tue, Mar 22, 2022 at 04:29:08PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 21, 2022 at 11:07 PM Pali Rohár <pali@...nel.org> wrote:
> > >
> > > Support for UPF_SPD_* flags is currently broken in more drivers for two
> > > reasons. First one is that uart_update_timeout() function does not
> > 
> > the uart_update_timeout()
> > 
> > > calculate timeout for UPF_SPD_CUST flag correctly. Second reason is that
> > > userspace termios structre is modified by most drivers after each
> > 
> > structure
> > 
> > ...
> > 
> > > (error handling was ommited for simplification)
> > 
> > omitted
> > 
> > > After calling set_active_spd_cust_baud() function SPD custom divisor
> > > should be active and therefore is_spd_cust_active() should return true.
> > >
> > > But it is not active (cfgetospeed does not return B38400) and this patch
> > > series should fix it. I have tested it with 8250 driver.
> > 
> > drivers
> > 
> > > Originally Johan Hovold reported that there may be issue with these
> > > ASYNC_SPD_FLAGS in email:
> > > https://lore.kernel.org/linux-serial/20211007133146.28949-1-johan@kernel.org/
> > >
> > >
> > > Johan, Greg, could you please test these patches if there is not any
> > > regression?
> > 
> > I'm wondering why we are still supporting this ugly hack?
> > Doesn't BOTHER work for you?
> 
> Yes, I too do not want to add more support for these old flags.  If they
> have not been working, let's not add support for them as obviously no
> one is using them.  Let's try to remove them if at all possible.

Well, it works partially. For more drivers SET method is working, but
GET method returns incorrect value. If your userspace application is
written in a way that does not retrieve from kernel current settings
then it has big probability that application works.

So, do you really want to remove support for these old flags completely?
That would of course break above applications.

Note that usage of BOTHER is problematic and in most cases highly
impossible if you are using glibc libc.so. BOTHER is incompatible with
glibc header files and so you can either include BOTHER/linux termios
file (exclusive) OR glibc header files.

New version of tcsetattr and ioctl_tty manpages would have documented
how to use BOTHER (it is currently in the manpages git).

Currently the only known option how to use BOTHER is to completely
reimplement all functions from "termios.h", provide custom "termios.h"
header file (and not use glibc termios.h nor any file which it includes)
and statically link this reimplementation into final application.

So in most cases BOTHER is not alternative to those old SPD flags even
for modern applications.

> thanks,
> 
> greg k-h