linux-kernel - RE: [PATCH 0/4] serial: 8250: Fixes for Oxford Semiconductor 950 UARTs

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2106260055211.37803@angie.orcam.me.uk>
Date:   Sat, 26 Jun 2021 06:13:26 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     David Laight <David.Laight@...LAB.COM>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/4] serial: 8250: Fixes for Oxford Semiconductor 950
 UARTs

On Tue, 15 Jun 2021, David Laight wrote:

> >  As I have noted above there is a data type signedness difference between
> > `mcr_mask' and UART_MCR_CLKSEL.  So we have the value of 0x80 (128).
> > Once bitwise-complemented it becomes 0xffffff7f (-129).  Once assigned to
> > `mcr_mask' however it becomes 0x7f (127), which is considered an unsafe
> > conversion between signed and unsigned integers by GCC, which is why the
> > compiler complains about it.
> 
> Blame the iso C standards committee for making integer promotions
> 'value preserving' instead of 'sign preserving' as they were in K&R C.
> 
> Try using ^ 0xffu instead of ~.

 Hmm, this is probably the least horrible way to paper it over, thanks.  
Even using a temporary variable (let alone a cast) does not help as GCC 
sees through it, and I've given up on converting <linux/serial_reg.h> to 
have e.g.:

#define UART_MCR_CLKSEL		_UL(0x80) /* Divide clock by 4 (TI16C752, EFR[4]=1) */

as I find that too messy with many of the comments wrapping up.  And using 
a GCC pragma would require a messy compiler version check.

 I have posted an update with a path-of-least-resistance fix then along 
with the 4/4 as v2 of this series.

  Maciej