linux-kernel - Re: RISCV Vector unit disabled by default for new task (was Re: [PATCH v12 17/17] riscv: prctl to enable vector commands)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 09 Dec 2022 13:32:33 +0100
From:   Florian Weimer <fweimer@...hat.com>
To:     Andrew Waterman <andrew@...ive.com>
Cc:     Palmer Dabbelt <palmer@...belt.com>,
        Vineet Gupta <vineetg@...osinc.com>, stillson@...osinc.com,
        Paul Walmsley <paul.walmsley@...ive.com>, anup@...infault.org,
        atishp@...shpatra.org, guoren@...nel.org,
        Conor Dooley <conor.dooley@...rochip.com>,
        greentime.hu@...ive.com, vincent.chen@...ive.com,
        andy.chiu@...ive.com, arnd@...nel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        bjorn@...nel.org, libc-alpha@...rceware.org,
        christoph.muellner@...ll.eu, Aaron Durbin <adurbin@...osinc.com>,
        linux@...osinc.com
Subject: Re: RISCV Vector unit disabled by default for new task (was Re:
 [PATCH v12 17/17] riscv: prctl to enable vector commands)

* Darius Rad:

> On Fri, Dec 09, 2022 at 11:02:57AM +0100, Florian Weimer wrote:
>> * Andrew Waterman:
>> 
>> > This suggests that ld.so, early-stage libc, or possibly both will need
>> > to make this prctl() call, perhaps by parsing the ELF headers of the
>> > binary and each library to determine if the V extension is used.
>> 
>> If the string functions use the V extension, it will be enabled
>> unconditionally.  So I don't see why it's okay for libc to trigger this
>> alleged UAPI change, when the kernel can't do it by default.
>> 
>
> Because the call to enable can fail and userspace needs to deal with that.

Failure is usually indicated by an AT_HWCAP or AT_HWCAP2 bit remaining
zero, or perhaps a special CPU register (although that is more unusual).
It's possible to do this differently, but every mid-level startup code
will have to replicate it (the libcs, other run-time environments like
Go, and so on).

Still it's much better than executing the instruction to see if it
traps, so I won't complain too much.

Thanks,
Florian