linux-kernel - Re: [RFC PATCH 0/2] Add support for SBI version to 0.2

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: <mhng-d7823725-b118-4588-bcec-e85354e52283@palmer-si-x1c4>
Date:   Mon, 16 Sep 2019 09:12:12 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...ive.com>
To:     Christoph Hellwig <hch@...radead.org>
CC:     aou@...s.berkeley.edu, alankao@...estech.com,
        alexios.zavras@...el.com, anup@...infault.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        linux-kernel@...r.kernel.org, rppt@...ux.ibm.com,
        Christoph Hellwig <hch@...radead.org>,
        Atish Patra <Atish.Patra@....com>, gary@...yguo.net,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-riscv@...ts.infradead.org, tglx@...utronix.de
Subject:     Re: [RFC PATCH 0/2] Add support for SBI version to 0.2

On Sun, 15 Sep 2019 23:54:46 PDT (-0700), Christoph Hellwig wrote:
> On Fri, Sep 13, 2019 at 08:54:27AM -0700, Palmer Dabbelt wrote:
>> On Tue, Sep 3, 2019 at 12:38 AM hch@...radead.org <hch@...radead.org> wrote:
>> 
>> > On Fri, Aug 30, 2019 at 11:13:25PM +0000, Atish Patra wrote:
>> > > If I understood you clearly, you want to call it legacy in the spec and
>> > > just say v0.1 extensions.
>> > > 
>> > > The whole idea of marking them as legacy extensions to indicate that it
>> > > would be obsolete in the future.
>> > > 
>> > > But I am not too worried about the semantics here. So I am fine with
>> > > just changing the text to v0.1 if that avoids confusion.
>> >
>> > So my main problems is that we are lumping all the "legacy" extensions
>> > together.  While some of them are simply a bad idea and shouldn't
>> > really be implemented for anything new ever, others like the sfence.vma
>> > and ipi ones are needed until we have hardware support to avoid them
>> > and possibly forever for virtualization.
>> >
>> > So either we use different markers of legacy for them, or we at least
>> > define new extensions that replace them at the same time.  What I
>> > want to avoid is the possibіly of an implementation using the really
>> > legacy bits and new extensions at the same time.
>> >
>> 
>> Nominally we've got to replace these as well because we didn't include
>> the length of the hart mask. 
>
> Well, let's do that as part of definining the first real post-0.1
> SBI then, and don't bother defining the old ones as legacy at all.
>
> Just two different specs that don't interact except that we reserve
> extension space in the new one for the old one so that one SBI spec
> can implement both.

Makes sense.  We're getting finish with this "just go write everything down" 
exercise, so we can start actually doing things now :).