Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 318
    • Issues 318
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 36
    • Merge requests 36
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #40423
Closed
Open
Created Jun 30, 2021 by Jim Newsome@jnewsomeOwner

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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking