linux-kernel - Re: [PATCH v3 2/2] proc: add /proc/<pid>/arch

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-a16f4bfc-7c48-4829-9ce6-3ff8b3e1241b@palmer-si-x1c4>
Date:   Wed, 21 Nov 2018 09:12:56 -0800 (PST)
From:   Palmer Dabbelt <palmer@...ive.com>
To:     peterz@...radead.org
CC:     aubrey.li@...ux.intel.com, aubrey.li@...el.com, tglx@...utronix.de,
        mingo@...hat.com, hpa@...or.com, ak@...ux.intel.com,
        tim.c.chen@...ux.intel.com, dave.hansen@...el.com,
        arjan@...ux.intel.com, linux-kernel@...r.kernel.org
Subject:     Re: [PATCH v3 2/2] proc: add /proc/<pid>/arch_state

On Wed, 21 Nov 2018 01:53:50 PST (-0800), peterz@...radead.org wrote:
> On Wed, Nov 21, 2018 at 09:19:36AM +0100, Peter Zijlstra wrote:
>> On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
>> > > Also; you were going to shop around with the other architectures to see
>> > > what they want/need for this interface. I see nothing on that.
>> > >
>> > I'm open for your suggestion, :)
>>
>> Well, we have linux-arch and the various maintainers are also listed in
>> MAINTAINERS. Go forth and ask..
>
> Ok, so I googled a wee bit (you could have too).
>
> There's not that many architectures that build big hot chips
> (powerpc,x86,arm64,s390) (mips, sparc64 and ia64 are pretty dead I
> think, although the Fujitsu Sparc M10 X+/X SIMD looked like it could be
> 'fun').
>
> Of those, powerpc altivec doesn't seem to be very wide, but you'd have
> to ask the power folks. Same for s390 z13.
>
> The Fujitsu/ARM64-SVE stuff looks like it can be big and hot.
>
> And RISC-V has was vector extention, but I don't think anybody is
> actually building big hot versions of that just yet.

We don't actually have a vector extension yet, but there's supposed to be a 
draft out in 2 weeks.  The plan is that this draft will be sufficiently 
long-lived that we can start software implementation work.  While I don't 
believe it's intended that hardware implementations become available using 
this draft specification, these things tend to take a life of their own.  I'd 
be pretty surprised if we don't end up seeing hardware implementations of this 
draft specification.

I don't know if they'll be big and hot, though -- the whole point of the vector 
extension is that we can build chips that aren't that big or hot :)

On a more serious note, in RISC-V land we've attempted to make mcontext 
extensible and plan on shimming all the additional architectural state into 
there.  Thus, I don't think this interface is particularly useful for us.

I also don't like this "file full of 1s and 0s" interface, but it's certainly 
not my place to shoot it down.  In RISC-V land we're trying very hard to 
carefully examine any user-visible ABI to ensure it's something we're willing 
to keep around for ever, and this doesn't seem like something that fits that 
mold.