linux-kernel - Re: [PATCH 0/4] Expose the isa-string via the AT_BASE

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: <CALs-HsveK-uUuSAOkUUPuUYK6_ChG95_YWtdwYvGsTfKYSWUpg@mail.gmail.com>
Date:   Mon, 8 May 2023 09:49:32 -0700
From:   Evan Green <evan@...osinc.com>
To:     Heiko Stübner <heiko@...ech.de>
Cc:     philipp.tomsich@...ll.eu, Palmer Dabbelt <palmer@...belt.com>,
        bjorn@...nel.org, jrtc27@...c27.com,
        linux-riscv@...ts.infradead.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        kito.cheng@...ive.com, Conor Dooley <conor.dooley@...rochip.com>,
        matthias.bgg@...il.com, heinrich.schuchardt@...onical.com,
        greentime.hu@...ive.com, nick.knight@...ive.com,
        christoph.muellner@...ll.eu,
        Richard Henderson <richard.henderson@...aro.org>,
        Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] Expose the isa-string via the AT_BASE_PLATFORM aux vector

On Wed, May 3, 2023 at 3:31 AM Heiko Stübner <heiko@...ech.de> wrote:
>
> Hi,
>
> Am Dienstag, 2. Mai 2023, 19:15:29 CEST schrieb Palmer Dabbelt:
> > On Tue, 02 May 2023 02:13:10 PDT (-0700), philipp.tomsich@...ll.eu wrote:
> > > On Tue, 2 May 2023 at 09:58, Björn Töpel <bjorn@...nel.org> wrote:
> > >>
> > >> Philipp Tomsich <philipp.tomsich@...ll.eu> writes:
> > >>
> > >> > It is a pity that the current interface was designed without involving
> > >> > RVI (and that I had to ask my team to put together a patch set for
> > >> > further discussion, given that none of the other major vendors in RVI
> > >> > stepped forward).  I guarantee that plenty of reviewers would have
> > >> > highlighted that a central registry (even if it is just a kernel
> > >> > header) should be avoided.
> > >>
> > >> Are you claiming that the hwprobe work was not done in the open, but
> > >> secretly merged? That is not only incorrect, but rude to upstream RISC-V
> > >> Linux developers. I suggest you review how you interact with upstream
> > >> kernel work.
> > >
> > > Please don't put words into my mouth...
> > >
> > > I was merely pointing out that there was no engagement by the RVI
> > > member companies (in regard to this mechanism) within RVI, which would
> > > have prevented Jessica's issue.
> > > This would have also helped to address the concerns on vendor-defined
> > > extensions.
> > >
> > > Also who do you refer to when you say "how _you_ interact"?  If it is
> > > RVI that you refer to: it doesn't interact with upstream work
> > > directly, as it doesn't own any engineering resources.
> > > RVI provides a forum for member companies to come to an
> > > understanding/design and then have the member companies perform the
> > > work and take it upstream.
> >
> > I'm not even sure what you're looking for here: if RVI doesn't want to
> > work upstream, then complaining that RVI isn't part of upstream
> > discussions is pretty pointless.
> >
> > >> Why didn't RVI get involved in the review of the series? The expectation
> > >> cannot be that all open source projects go to RVI, but rather the other
> > >> way around.
> > >
> > > That is exactly the point I was making and which you seem to miss: RVI
> > > does not own any engineering resources and depends solely on its
> > > member companies to project into open source projects.
> > >
> > >> Take a look at commit ea3de9ce8aa2 ("RISC-V: Add a syscall for HW
> > >> probing"). Your team was very much involved in the review.
> > >
> > > I am aware, as I had reviewed and commented on these are well.
> > > And my only request (was and) is that we need to figure out a way to
> > > efficiently deal with vendor-defined extensions.
> >
> > Maybe you should go talk to you team, then?  Handling vendor extensions
> > via hwprobe has been discussed, sounds like you're confused again.
>
> I too have this vague memory of us talking about vendor extensions,
> but my memory is really bad for stuff like this, so I spent the morning
> combing through all the hwprobe iterations looking for it, but so far
> have only found
>
> https://lore.kernel.org/lkml/CALs-HstoeoTWjTEZrLWouCgwq0t3tDB6uL=tB68RJDs1ub4Frw@mail.gmail.com/
>
> I'm most likely just blind, but does someone have another pointer?

Hello! That's probably the only pointer.

Couldn't handling vendor extensions within the hwprobe framework be as
straightforward as explicitly carving out a region for them? Say
0x8000000000000000+ belongs to the vendor? The layout of keys within
the vendor hwprobe region then depends on the value in mvendorid (and
if the vendor so chooses, archid and impid as well). Then vendors can
expose keys to their hearts (avoiding the dumb pun there) content.

We can probably skip caching the vendor keys in the vDSO for now. If
it really needs to be done we can add it later.

This would enforce that there's only one "vendor" at a time for a
given hart, but I think that's reasonable. Let me know what you think.

-Evan