linux-kernel - Re: [PATCH V2 1/2] riscv: Add RISC-V svpbmt 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>] [day] [month] [year] [list]

Message-ID: <CAOnJCU+tw1Lsjk8YvNumz0nztT+7p9KppufyTc5JZudi6krKwg@mail.gmail.com>
Date:   Mon, 27 Sep 2021 23:14:42 -0700
From:   Atish Patra <atishp@...shpatra.org>
To:     Greg Favor <gfavor@...tanamicro.com>
Cc:     Anup Patel <anup@...infault.org>,
        Nick Kossifidis <mick@....forth.gr>,
        Guo Ren <guoren@...nel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Anup Patel <anup.patel@....com>,
        Atish Patra <atish.patra@....com>,
        Palmer Dabbelt <palmerdabbelt@...gle.com>,
        Christoph Müllner <christoph.muellner@...ll.eu>,
        Philipp Tomsich <philipp.tomsich@...ll.eu>,
        Christoph Hellwig <hch@....de>,
        liush <liush@...winnertech.com>, wefu@...hat.com,
        Wei Wu (吴伟) <lazyparser@...il.com>,
        Drew Fustini <drew@...gleboard.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        taiten.peng@...onical.com,
        Aniket Ponkshe <aniket.ponkshe@...onical.com>,
        Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
        Gordan Markus <gordan.markus@...onical.com>,
        Guo Ren <guoren@...ux.alibaba.com>,
        Arnd Bergmann <arnd@...db.de>, Chen-Yu Tsai <wens@...e.org>,
        Maxime Ripard <maxime@...no.tech>,
        Daniel Lustig <dlustig@...dia.com>,
        Andrea Mondelli <andrea.mondelli@...wei.com>,
        Jonathan Behrens <behrensj@....edu>,
        Xinhaoqu <xinhaoqu@...wei.com>,
        Bill Huffman <huffman@...ence.com>,
        Allen Baum <allen.baum@...erantotech.com>,
        Josh Scheid <jscheid@...tanamicro.com>,
        Richard Trauben <rtrauben@...il.com>
Subject: Re: [PATCH V2 1/2] riscv: Add RISC-V svpbmt extension

On Mon, Sep 27, 2021 at 9:49 PM Greg Favor <gfavor@...tanamicro.com> wrote:
>
> On Mon, Sep 27, 2021 at 9:26 PM Atish Patra <atishp@...shpatra.org> wrote:
>>
>> IMHO, if we want to support this board in upstream, we should just
>> clearly state that it is one time special exception
>> for this board only because of the following reasons
>
>
> I'm not quite following what the exception is?  If RVI's policy is followed for how software support for custom extensions (which D1 falls under) should be handled (as part of allowing such software to be upstreamed), then that doesn't burden standard distros nor the community to maintain ongoing support.

I am a bit confused. As per our understanding, D1 doesn't fall under
custom extensions because they have non-standard conflicting
implementations of the PTE bits that violate the privilege
specification (v1.12 with svpbmt & svnapot extension merged).
Custom extensions can only be defined via satp mode (14-15). Am I
missing something?

>  And this doesn't stop a custom Linux build from being provided to users of the D1 board (like what any other vendor would need to do to support the custom extensions on their hardware).

A custom Linux build is already floating around for the users for the
D1 board. Whether the upstream mainline kernel supports this board is
the key question here.

>
> Or are you proposing that standard binary distros would have to support D1's custom extension?  (And how would that even work if and when Svpbmt becomes required in some rev of the OS-A platform spec - at which point the D1 boards have a nonconforming extension that can't be disabled and thus conflicts with required (Svpbmt) functionality?)

I was suggesting to support D1 in the unified kernel image built from
defconfig only if we decide to support it.
standard binary distros(such as Fedora, RHEL, Suse, Ubuntu) anyways
use custom config. They can always disable support for D1 if they want
it.

>
> Greg
>
>>
>>
>> 1. The board design predates the patch acceptance policy.
>> 2. We don't have enough affordable Linux compatible platforms today.
>> 3. Allowing running an upstream kernel on D1 helps the RISC-V software
>> ecosystem to grow.
>>
>> No more exceptions will be allowed in future for such hardware that
>> violates the spec. Period.
>>
>> > Regards,
>> > Anup
>>
>>
>>
>> --
>> Regards,
>> Atish



--
Regards,
Atish