linux-kernel - Re: [PATCH 00/14] alpha: cleanups for 6.10

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: Tue, 2 Jul 2024 00:48:36 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: "Paul E. McKenney" <paulmck@...nel.org>, 
    John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
    Arnd Bergmann <arnd@...nel.org>, linux-alpha@...r.kernel.org, 
    Arnd Bergmann <arnd@...db.de>, 
    Richard Henderson <richard.henderson@...aro.org>, 
    Ivan Kokshaysky <ink@...assic.park.msu.ru>, 
    Matt Turner <mattst88@...il.com>, Alexander Viro <viro@...iv.linux.org.uk>, 
    Marc Zyngier <maz@...nel.org>, linux-kernel@...r.kernel.org, 
    Michael Cree <mcree@...on.net.nz>, Frank Scheiner <frank.scheiner@....de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10

On Mon, 3 Jun 2024, Linus Torvalds wrote:

> >  Anyway, back to my point.  A feasible solution non-intrusive for Linux
> > and low-overhead for GCC has been found.  I can expedite implementation
> > and I'll see if I can regression-test it too, but I may have to rely on
> > other people to complete it after all, as I haven't been prepared for this
> > effort in the light of certain issues I have recently suffered from in my
> > lab.
> 
> Yeah, if compiler support makes us not have to care, then I don't
> think the difference between pre-BWX and BWX is going to matter much
> for the kernel.
> 
> The real pain with alpha has been that it's special enough that it
> affects non-alpha code, and BWX was one big piece of that.

 Understood, that's burden beyond justification for an obsolete legacy 
platform.

> That said, some of the EV4 misfeatures end up being a huge pain inside
> the alpha code either because of the horrible hoops that the IO
> accessors have to jump through, or because of the broken ASID's.
> 
> So even with enw compiler support, maybe it's worth trying to
> re-introduce any support for older cpu's incrementally.

 Ack.

> For example, the ASID hw issue is _claimed_ to have been fixed in
> PALcode, and maybe the games we played for ev4-era cpus aren't
> actually needed any more?

 Actually my system seems to be an odd relic that has very old PALcode:

[...]
X3.7-10895, built on Sep 15 1994 at 10:19:05
>>>sh conf

SRM Console X3.7-10895  VMS PALcode X5.48-60, OSF PALcode X1.35-42
[...]

-- which is dated well before the system's release date.  It has been 
heavily patched with extra components retrofitted on the PCB as if an 
early hardware revision and the part number labelled on the PCB it's an 
AlphaStation 250 and yet it came packaged as AlphaServer 300 (the only 
documented difference between the PCBs of the two systems is the maximum 
amount of DRAM supported), with a vast mismatch between the dates given on 
the PCB and the case.  I don't know what's the story behind it, maybe it 
once was a DEC engineering machine.

 And for instance its SRM cannot netboot over BOOTP/TFTP, it can only 
use MOP.  Not an issue for me, and I feel a bit uneasy about upgrading the 
firmware, I'd rather I didn't brick the machine.  I guess we shall see 
whether it matters and if so, then what can be done about it.

 I used an AlphaServer 300 before that was purchased brand new and I can't 
recall any such patching on the PCB, and I reckon SRM was more modern too.
Indeed having checked old logs I found:

[...]
version                 X6.2-165 Nov  4 1996 10:06:10
>>>sh conf

Firmware
SRM Console:    X6.2-165
ARC Console:    4.49
PALcode:        VMS PALcode V5.56-2, OSF PALcode X1.46-2
[...]

> And the various odd IO platforms should only be re-introduced when
> there are people who actually have access to the relevant hardware and
> will test.

 Absolutely, what's the point of keeping something we have no way to
verify?  I'll begin with what I'm interested in myself and will gather 
input from people willing to verify stuff with other hardware they may 
have.

 Anyway, it's been a hectic month for me and I have my Alpha machine in 
the remote lab fully ready for this effort now, with a number of issues 
fixed, most importantly rather tricky GCC PR rtl-optimization/115565, 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565> which prevented the 
userland from being used as installed.

 With that in place the system was able to complete GCC 15 verification, 
so now it should be able to do pretty much anything.  I ran some glibc 
upstream master testing too.

 With that ticked off I do hope to work on the GCC part throughout July, 
and then the kernel bits will follow.

  Maciej