seccomp sandbox is disabling speculative stores, which hurts performance and doesn't have a security benefit in this case
tor uses a seccomp sandbox (via libseccomp) and does not opt out of the Speculative Store Bypass mitigation.
The Speculative Store Bypass mitigation disables speculative stores on the CPU, which can have a very negative effect on CPU performance. e.g. in some Shadow simulations (not of tor), we saw a 50% performance penalty when this mitigation was enabled: https://github.com/shadow/shadow/issues/1489.
The vulnerability itself is only useful to code that wants to steal secrets from other code with access to the same memory. e.g. it's useful for malicious javascript in a vulnerable web browser, since it runs in the same address space as the browser but is otherwise prevented from reading arbitrary memory in the space.
e.g. from: https://www.redhat.com/en/blog/speculative-store-bypass-explained-what-it-how-it-works
As a result, untrusted (possibly malicious) code can run within a sandbox and abuse store buffer speculation to read sensitive data from the sandbox itself.
IIUC, in tor's case, the code being sandboxed is hypothetical code injected via a buffer overflow etc. Such code can already read all of the tor process's memory, which means it has nothing further to gain through the speculative store bypass attack, which means tor has nothing to gain from the speculative store bypass mitigation.
I believe we should opt tor out of this mitigation, which can be achieved by calling seccomp_attr_set with SCMP_FLTATR_CTL_SSB set to 1.