linux-kernel - Re: Old platforms: bring out your dead

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: <CACwypyNVibQby75dZek=P1oBkcHQYMx-kbria9Y6NnBpERh+qQ@mail.gmail.com>
Date:   Mon, 11 Jan 2021 19:50:48 -0500
From:   chase rayfield <cusbrar1@...il.com>
To:     Rob Landley <rob@...dley.net>
Cc:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        Sam Ravnborg <sam@...nborg.org>, Arnd Bergmann <arnd@...db.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Sparc kernel list <sparclinux@...r.kernel.org>,
        Linux-sh list <linux-sh@...r.kernel.org>
Subject: Re: Old platforms: bring out your dead

> Sparc has a runtime relocation I've never understood but did manage to break
> once, resulting in a long thread to fix:
>
> http://lists.landley.net/pipermail/aboriginal-landley.net/2011-December/001964.html
>
> Between that and the weird save half the stack register thing with function
> calls on some sort of "wheel"... there's a _reason_ I haven't been able to talk
> Rich into adding support for it to musl.
>
Register windowing, with parts of each window overlapping for function
arguments etc... you can kind of think of it as a ring buffer of
overlapping register files that's an oversimplification but it was
originally intended to accelerate and improve register file usage.
MIPS and the rest of the industry abandoned this for improved compile
time allocation. I think you might be more likely on MIPS to incur
more interrupt latency though since you have to spill to memory (at
least on MIPS contemporary to Sparc V8) instead of just switching
register windows mileage varies greatly.... From what I remember
overflowing the register file is implemented with hardware traps that
spill to memory etc... since you don't know that information at
compile time. on Sparc so yeah it's quite involved to understand and I
certainly don't grasp it fully. So on MIPS you spill the register file
to memory, on Sparc you spill register windows to memory... if you
have exceeded the supported call depth (which is rather expensive
since all the register windows go at once). Note spilling a single
variable within a register window is a separate issue.

Amazing, a link that actually works and is informative:
https://blogs.oracle.com/d/flush-register-windows


Chase