Increasingly complex RISC-V cores aren’t magically immune to the speculative execution / side-channel vulnerabilities that have rattled the x86_64 and ARM64 landscape for years. Following recent work on Spectre V1 handling for RISC-V in the Linux kernel, merged this weekend for Linux 6.19-rc5 is another RISC-V attack vector safeguard.
A patch was merged on Saturday in time for today’s Linux 6.19-rc5 release as another security improvement for RISC-V. The RISC-V architecture code in the Linux kernel is now sanitizing the system call table indexing under speculation, similar to how the code is already handled in the x86 and ARM space. Due to the system call nu…
Increasingly complex RISC-V cores aren’t magically immune to the speculative execution / side-channel vulnerabilities that have rattled the x86_64 and ARM64 landscape for years. Following recent work on Spectre V1 handling for RISC-V in the Linux kernel, merged this weekend for Linux 6.19-rc5 is another RISC-V attack vector safeguard.
A patch was merged on Saturday in time for today’s Linux 6.19-rc5 release as another security improvement for RISC-V. The RISC-V architecture code in the Linux kernel is now sanitizing the system call table indexing under speculation, similar to how the code is already handled in the x86 and ARM space. Due to the system call number being a user-controlled value for indexing into the syscall table, special handling is needed to prevent speculative out-of-bounds access and possible data leakage via cache side channels.
Yesterday’s RISC-V fixes merge to Linux 6.19 Git commented:
"Notable changes include a fix to close one common microarchitectural attack vector for out-of-order cores. ... Prevent branch predictor poisoning microarchitectural attacks that use the syscall index as a vector by using array_index_nospec() to clamp the index after the bounds check (as x86 and ARM64 already do)."
Look for this and the other fixes that landed this week in Linux 6.19-rc5 due out later today.