linux-kernel - Re: PROBLEM: kbd busted in linux 6.10-rc1 (regression)

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: <d7412ef9-8e25-4f55-aac9-8ec479fb6775@draconx.ca>
Date: Wed, 29 May 2024 01:36:28 -0400
From: Nick Bowler <nbowler@...conx.ca>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: linux-kernel@...r.kernel.org,
 Linux regressions mailing list <regressions@...ts.linux.dev>,
 Alexey Gladkov <legion@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: PROBLEM: kbd busted in linux 6.10-rc1 (regression)

On 2024-05-29 01:25, Al Viro wrote:
> On Wed, May 29, 2024 at 12:45:56AM -0400, Nick Bowler quoted:
> 
>>        All other headers use _IOC() macros to describe ioctls for a long time
>>        now. This header is stuck in the last century.
>>    
>>        Simply use the _IO() macro. No other changes.
> 
> ... are needed, since _IO() is arch-dependent; this is quite enough to fuck
> alpha and sparc over.  _IO(x,y) is (1<<29) + 256*x + y there; both ports
> got started with compat userland support, so _IO...() family there is
> modelled after OSF/1 and Solaris resp.
>
> kbd ioctls predate all of that.
> 
> Please, revert 8c467f330059 - commit in question breaks userland on alpha
> and on sparc for no reason whatsoever.  Might be worth adding a comment
> to those definitions at some point, but that can go on top of revert.

FWIW I see exactly the same problem with 6.10-rc1 on powerpc too.

> Folks, 0xXYZW is *not* an uncool way to spell _IO(0xXY,0xZW) - if there's
> any chance that those definitions are seen on all architectures, they
> should be left alone.

Thanks,
  Nick