linux-kernel - Re: [PATCH] serial: 8250: Fix reporting real baudrate value in c

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: <YVGVHzHzhOjUp7b8@kroah.com>
Date:   Mon, 27 Sep 2021 11:55:43 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Pali Rohár <pali@...nel.org>
Cc:     Jiri Slaby <jirislaby@...nel.org>, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] serial: 8250: Fix reporting real baudrate value in
 c_ospeed field

On Mon, Sep 27, 2021 at 11:37:04AM +0200, Pali Rohár wrote:
> In most cases it is not possible to set exact baudrate value to hardware.

Why not?

> So fix reporting real baudrate value which was set to hardware via c_ospeed
> termios field. It can be retrieved by ioctl(TCGETS2) from userspace.
> 
> Real baudrate value is calculated from chosen hardware divisor and base
> clock. It is implemented in a new function serial8250_compute_baud_rate()
> which is inverse of serial8250_get_divisor() function.
> 
> With this change is fixed also UART timeout value (it is updated via
> uart_update_timeout() function), which is calculated from the now fixed
> baudrate value too.

I can not parse this sentence, sorry.  Can you try to rephrase it
differently?

> 
> Signed-off-by: Pali Rohár <pali@...nel.org>
> Cc: stable@...r.kernel.org
> ---
> 
> I have tested this change on device with 8250 compatible UART. I have not
> tested it on PORT_NPCM nor on UPF_MAGIC_MULTIPLIER hardware, as I do not
> have such.
> 
> Tested device has 250 MHz base clock for 8250 UART. When I set baudrate to
> 115200, then ioctl(TCGETS2) reported B115200 CBAUD flag and value 114890 in
> c_ospeed field.
> 
> This result is correct as HW for baudrate 115200 is using UART divisor 136,
> which results in correct reported baudrate: 250000000/(16*136) = 114890

So is this going to break all the userspace tools that set a baud rate
and then read it back and get a different number than what they thought
they set?

That feels very dangerous.  Why does this matter?

> ---
>  drivers/tty/serial/8250/8250_port.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 66374704747e..dc6900b2daa8 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -2584,6 +2584,19 @@ static unsigned int serial8250_get_divisor(struct uart_port *port,
>  	return serial8250_do_get_divisor(port, baud, frac);
>  }
>  
> +static unsigned int serial8250_compute_baud_rate(struct uart_port *port,
> +						 unsigned int quot)
> +{
> +	if ((port->flags & UPF_MAGIC_MULTIPLIER) && quot == 0x8001)
> +		return port->uartclk / 4;
> +	else if ((port->flags & UPF_MAGIC_MULTIPLIER) && quot == 0x8002)
> +		return port->uartclk / 8;
> +	else if (port->type == PORT_NPCM)
> +		return DIV_ROUND_CLOSEST(port->uartclk - 2 * (quot + 2), 16 * (quot + 2));
> +	else
> +		return DIV_ROUND_CLOSEST(port->uartclk, 16 * quot);
> +}

Where did these formulas come from?

thanks,

greg k-h