linux-kernel - Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension

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: <CAK8P3a2Mr_z6h7eg1O8ZN5_qE-o+8KFFBum3CxyuDYeF50s1dw@mail.gmail.com>
Date:   Wed, 9 Mar 2022 11:02:27 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     "Michael T. Kloos" <michael@...haelkloos.com>
Cc:     Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension

On Wed, Mar 9, 2022 at 6:28 AM Michael T. Kloos
<michael@...haelkloos.com> wrote:
>
> Added a new config symbol RISCV_ISA_M to enable the usage of the
> multiplication, division, and remainder (modulus) instructions
> from the M-extension.  This configures the march build flag to
> either include or omit it.
>
> I didn't find any assembly using any of the instructions from
> the M-extension.  However, the BPF JIT is a complicating factor.
> Currently, it emits M-extension instructions to implement various
> BPF operations.  For now, I have made HAVE_EBPF_JIT depend on
> CONFIG_RISCV_ISA_M.
>
> I have added the supplementary integer arithmetic functions in
> the file "arch/riscv/lib/ext_m_supplement.c".  All the code
> contained in this file is wrapped in an ifndef contingent on the
> presence of CONFIG_RISCV_ISA_M.
>
> Signed-off-by: Michael T. Kloos <michael@...haelkloos.com>

The patch looks fine to me, but I increasingly get the feeling that the
entire platform feature selection in Kconfig should be guarded with
a global flag that switches between "fully generic" and "fully custom"
builds, where the generic kernel assumes that all the standard
features (64-bit, C, M, FPU, MMU, UEFI, ...) are present, the
incompatible options (XIP, PHYS_RAM_BASE_FIXED,
CMDLINE_FORCE, BUILTIN_DTB, ...) are force-disabled,
and all optional features (V/B/P/H extensions, custom instructions,
platform specific device drivers, ...) are runtime detected.

At the moment, those three types are listed at the same level,
which gives the impression that they can be freely mixed.

         Arnd