On 21.02.2024 13:47, Oleksii wrote: > As I understand it, evaluate_nospec()/block_speculation() were > introduced for x86 to address the L1TF vulnerability specific to x86 > CPUs.
Well, if you look at one of the later commits altering x86'es variant, you'll find that this wasn't really correct. > This vulnerability is exclusive to x86 architectures [1], which > explains why evaluate_nospec()/block_speculation() are left empty for > Arm, RISC-V, and PPC. > > It is unclear whether these functions should be utilized to mitigate > other speculation vulnerabilities. If they should, then, based on the > current implementation, the Arm platform seems to accept having > speculative vulnerabilities. > > The question arises: why can't other architectures make their own > decisions regarding security? By default, if an architecture leaves the > mentioned functions empty, it implies an agreement to potentially have > speculative vulnerabilities. Subsequently, if an architecture needs to > address such vulnerabilities, they can develop arch-specific nospec.h > to implement the required code. You can't take different perspectives on security. There is some hardening which one architecture may go farther with than another, but e.g. information leaks are information leaks and hence need addressing. Of course if an arch knew it had no (known) issues, then using a generic form of this header would be okay (until such time where an issue would be found). And btw, looking at how xen/nospec.h came about, it looks pretty clear to me that array_index_mask_nospec() should move from system.h to nospec.h. That would make Arm's form immediately different from what a generic one might have, and quite likely an inline assembly variant could also do better on RISC-V (unless, as said, RISC-V simply has no such issues). Then again I notice Arm64 has no override here ... Jan
