[PATCH] RISC-V: Clobber V registers on syscalls

[Palmer Dabbelt]

On Thu, 15 Jun 2023 10:36:31 PDT (-0700), remi at remlab.net wrote:
> Le keskiviikkona 14. kesäkuuta 2023, 19.35.34 EEST Palmer Dabbelt a écrit :
>> The V registers are clobbered by standard ABI functions, so userspace
>> probably doesn't have anything useful in them by the time we get to the
>> kernel.
>
> Indeed, for your typical system call, wrapped by two or more layers of 
> function calls inside libc, userspace will treat the registers as clobbered 
> anyhow.
>
> But AFAIU, other architectures don't gratuitiously clobber SIMD or vector 
> registers, even those that are callee-clobbered by their respective function 
> calling convention, or do they?

IIUC arm64 has some similar code, at least that's what the comment says 
(and I got the clobbering V state from Arm)

    /*
     * As per the ABI exit SME streaming mode and clear the SVE state not
     * shared with FPSIMD on syscall entry.
     */
    static inline void fp_user_discard(void)

if we don't clobber on syscalls then we'll likely need some way for 
userspace to inform the kernel that V state can be discarded.

> FWIW, Arm is going the opposite direction with 
> their higher privilege calls (newer versions of SMCCC define how to preserve 
> SVE vectors).

That has a slightly different cost structure, though: in the kernel V 
would usually be off, so there's already a strong indication when the 
save/restore is useful.

> The kernel cannot simply clobber registers, as that would likely cause data 
> leakage from kernel to user mode. So it is unclear what the benefits would be 

What's the data leakage?  Unless I'm missing something setting the 
sstatus.vs=off will result in userspace trapping in any V state access, 
so if we're leaking something we're probably also at risk of leaking it 
for new/cloned processes.

That said, we do need to think about speculative side-channels: with the 
V crypto stuff there will be keys in V registers and other architectures 
have had exploitable issues related to lazy save/restore and 
speculation.  Maybe it's best to just wait on that, though?  We'd 
ideally want some canonical sequence in the ISA but the fastest way to 
do that is probably to just wait for an exploit to show up.

> here. And I fear that there will be less conventional use cases whence it 
> makes sense to preserve registers on system calls.
>
> For example an inline or compiler intrinsic implementation of C++20/C2X 
> atomic-wait/atomic-notify, which would presumably invoke the futex() syscall 
> on Linux, maybe??

It'd have to be a pretty special case: at least in libstdc++ and glibc 
the futex calls are behind function calls, so the V registers are 
already clobbered by the time the kernel has been entered (at least for 
anything following the standard ABIs).

>
> -- 
> 雷米‧德尼-库尔蒙
> http://www.remlab.net/