linux-kernel - Re: [PATCH] DEC: Limit PMAX memory probing to R3k systems

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: <20220307122102.GC14422@alpha.franken.de>
Date:   Mon, 7 Mar 2022 13:21:02 +0100
From:   Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Jan-Benedict Glaw <jbglaw@...-owl.de>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Ralf Baechle <ralf@...ux-mips.org>, linux-mips@...r.kernel.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] DEC: Limit PMAX memory probing to R3k systems

On Fri, Mar 04, 2022 at 08:16:23PM +0000, Maciej W. Rozycki wrote:
> Recent tightening of the opcode table in binutils so as to consistently 
> disallow the assembly or disassembly of CP0 instructions not supported 
> by the processor architecture chosen has caused a regression like below:
> 
> arch/mips/dec/prom/locore.S: Assembler messages:
> arch/mips/dec/prom/locore.S:29: Error: opcode not supported on this processor: r4600 (mips3) `rfe'
> 
> in a piece of code used to probe for memory with PMAX DECstation models, 
> which have non-REX firmware.  Those computers always have an R2000 CPU 
> and consequently the exception handler used in memory probing uses the 
> RFE instruction, which those processors use.
> 
> While adding 64-bit support this code was correctly excluded for 64-bit 
> configurations, however it should have also been excluded for irrelevant 
> 32-bit configurations.  Do this now then, and only enable PMAX memory 
> probing for R3k systems.
> 
> Reported-by: Jan-Benedict Glaw <jbglaw@...-owl.de>
> Reported-by: Sudip Mukherjee <sudipm.mukherjee@...il.com>
> Signed-off-by: Maciej W. Rozycki <macro@...am.me.uk>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@...r.kernel.org # v2.6.12+
> ---
> Hi,
> 
>  I'm assuming this won't go back beyond commit 2a11c8ea20bf ("kconfig: 
> Introduce IS_ENABLED(), IS_BUILTIN() and IS_MODULE()") or any backport 
> will have to be rewritten to avoid IS_ENABLED.
> 
>  The original actual change named to fix ought to be commit dd82ef87e4c9 
> ("PROM interface rework to support a 64-bit kernel.") from the LMO repo: 
> <https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=dd82ef87e4c9>, 
> which introduced the `prom_is_rex' macro, which guards this code.  Said 
> commit predates the history of our main repository though.
> 
>  This change has actually been verified at runtime with a PMIN system 
> (effectively a PMAX, but with a slower R2000 CPU) and a 4MAX+ system (an 
> R4400SC-based machine), and naturally throughout the three possible build 
> configurations: R3k, R4k/32-bit, R4k/64-bit.
> 
>  It took longer than expected, but oh well...  Sorry for the inconvenience 
> caused.
> 
>  Please apply,
> 
>   Maciej
> ---
>  arch/mips/dec/prom/Makefile      |    2 +-
>  arch/mips/include/asm/dec/prom.h |   15 +++++----------
>  2 files changed, 6 insertions(+), 11 deletions(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]