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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 15 Dec 2022 07:33:53 -0800
From:   Richard Henderson <richard.henderson@...aro.org>
To:     Florian Weimer <fweimer@...hat.com>,
        Björn Töpel <bjorn@...nel.org>
Cc:     Darius Rad <darius@...espec.com>,
        Vineet Gupta <vineetg@...osinc.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Andrew Waterman <andrew@...ive.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,
        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)

On 12/15/22 04:28, Florian Weimer via Libc-alpha wrote:
> * Björn Töpel:
> 
>>> For SVE, it is in fact disabled by default in the kernel.  When a thread
>>> executes the first SVE instruction, it will cause an exception, the kernel
>>> will allocate memory for SVE state and enable TIF_SVE.  Further use of SVE
>>> instructions will proceed without exceptions.  Although SVE is disabled by
>>> default, it is enabled automatically.  Since this is done automatically
>>> during an exception handler, there is no opportunity for memory allocation
>>> errors to be reported, as there are in the AMX case.
>>
>> Glibc has an SVE optimized memcpy, right? Doesn't that mean that pretty
>> much all processes on an SVE capable system will enable SVE (lazily)? If
>> so, that's close to "enabled by default" (unless SVE is disabled system
>> wide).
> 
> Yes, see sysdeps/aarch64/multiarch/memcpy.c:
> 
>    static inline __typeof (__redirect_memcpy) *
>    select_memcpy_ifunc (void)
>    {
>      INIT_ARCH ();
>    
>      if (sve && HAVE_AARCH64_SVE_ASM)
>        {
>          if (IS_A64FX (midr))
>            return __memcpy_a64fx;
>          return __memcpy_sve;
>        }
>    
>      if (IS_THUNDERX (midr))
>        return __memcpy_thunderx;
>    
>      if (IS_THUNDERX2 (midr) || IS_THUNDERX2PA (midr))
>        return __memcpy_thunderx2;
>    
>      if (IS_FALKOR (midr) || IS_PHECDA (midr))
>        return __memcpy_falkor;
>    
>      return __memcpy_generic;
>    }
>    
> And the __memcpy_sve implementation actually uses SVE.
> 
> If there were a prctl to select the vector width and enable the vector
> extension, we'd have to pick a width in glibc anyway.

There *is* a prctl to adjust the SVE vector width, but glibc does not need to select 
because SVE dynamically adjusts to the currently enabled width.  The kernel selects a 
default width that fits within the default signal frame size.

The other thing of note for SVE is that, with the default function ABI all of the SVE 
state is call-clobbered, which allows the kernel to drop instead of save state across 
system calls.  (There is a separate vector function call ABI when SVE types are used.)

So while strcpy may enable SVE for the thread, the next syscall may disable it again.


r~