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: <mhng-1ed81282-b17a-43ef-9030-fc538d96892b@palmer-mbp2014>
Date:   Wed, 09 Mar 2022 23:34:27 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     michael@...haelkloos.com, Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject:     Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension

On Wed, 09 Mar 2022 02:02:27 PST (-0800), Arnd Bergmann wrote:
> 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.

That'd be wonderful, but unfortunately we're trending the other way -- 
we're at the point where "words in the specification have meaning" is 
controversial, so trying to talk about which flavors of the 
specification are standard is just meaningless.  I obviously hope that 
gets sorted out, as we've clearly been pointed straight off a cliff for 
a while now, but LMKL isn't the place to have that discussion.  We've 
all seen this before, nobody needs to be convinced this leads to a mess.

Until we get to the point where "I wrote 'RISC-V' on that potato I found 
in my couch" can be conclusively determined not compliant with the spec, 
it's just silly to try and talk about what is.

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