linux-kernel - [PATCH 0/2] (attempt to) Fix RISC-V toolchain extension support detection

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

Message-Id: <20221006173520.1785507-1-conor@kernel.org>
Date:   Thu,  6 Oct 2022 18:35:19 +0100
From:   Conor Dooley <conor@...nel.org>
To:     Palmer Dabbelt <palmer@...belt.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Tom Rix <trix@...hat.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Dao Lu <daolu@...osinc.com>, Heiko Stuebner <heiko@...ech.de>,
        Guo Ren <guoren@...nel.org>, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: [PATCH 0/2] (attempt to) Fix RISC-V toolchain extension support detection

From: Conor Dooley <conor.dooley@...rochip.com>

Hey,
This came up due to a report from Kevin @ kernel-ci, who had been
running a mixed configuration of GNU binutils and clang. Their compiler
was relatively recent & supports Zicbom but binutils @ 2.35.2 did not.

Our current checks for extension support only cover the compiler, but it
appears to me that we need to check both the compiler & linker support
in case of "pot-luck" configurations that mix different versions of
LD,AS,CC etc.

Linker support does not seem possible to actually check, since the ISA
string is emitted into the object files - so I put in version checks for
that. The checks have gotten a bit ugly since 32 & 64 bit support need
to be checked independently but ahh well.

As I was going, I fell into the trap of there being duplicated checks
for CC support in both the Makefile and Kconfig, so as part of renaming
the Kconfig symbol to TOOLCHAIN_HAS_FOO, I dropped the extra checks in
the Makefile. This has the added advantage of the TOOLCHAIN_HAS_FOO
symbol for Zihintpause appearing in .config.

I pushed out a version of this that specificly checked for assember
support for LKP to test & it looked /okay/ - but I did some more testing
today and realised that this is redudant & have since dropped the as
check.

I tested locally with a fair few different combinations, to try and
cover each of AS, LD, CC missing support for the extension.

The one that I am left wondering about is Zicsr/Zifencei. Our Makefile
has:

> # Newer binutils versions default to ISA spec version 20191213 which moves some
> # instructions from the I extension to the Zicsr and Zifencei extensions.
> toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei)
> riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei

I'd like to also move that one to Kconfig rather than the Makefile so
that, again, it shows up in .config etc. But as Zicsr/Zifencei do not
appear to be emitted into the object files it's not a fix and can be a
follow-on patch if my approach here is not entirely off-the-wall.

I am not 100% on the LD/LLD versions that I picked, I went off of a
`git branch -a --contains` of the first commits I found that with
mention of the extension. Please scream if I got it wrong, I'm not
overly familar with where to find this sort of info for the toolchains.

Thanks,
Conor.

Conor Dooley (2):
  riscv: fix detection of toolchain Zicbom support
  riscv: fix detection of toolchain Zihintpause support

 arch/riscv/Kconfig                      | 17 +++++++++++++----
 arch/riscv/Makefile                     |  6 ++----
 arch/riscv/include/asm/vdso/processor.h |  2 +-
 3 files changed, 16 insertions(+), 9 deletions(-)

-- 
2.37.3