[llvm][clang] Sandbox filesystem reads#165350
Merged
jansvoboda11 merged 22 commits intollvm:mainfrom Dec 11, 2025
Merged
Conversation
jansvoboda11
force-pushed
the
sandboxing-v2
branch
2 times, most recently
from
b062e35 to
8e49476
Compare
benlangmuir
reviewed
Nov 6, 2025
| } | ||
|
|
||
| std::error_code is_other(const Twine &Path, bool &Result) { | ||
| sandbox::violationIfEnabled(); |
Collaborator
There was a problem hiding this comment.
Won't we catch these via status being a violation? Similarly for the other APIs here (e.g. openFileForRead).
Contributor
Author
There was a problem hiding this comment.
Yes, but I wanted to explicitly mark each API we expect to cause a sandbox violation. This is still conceptually an API that's required to touch the real FS. If the implementation ever changes from calling sys::fs::status() to calling status() directly, I still want this to remain a violation. Same goes for the other APIs.
Collaborator
There was a problem hiding this comment.
It seems hard to be completely safe against any possible future change like that. For example, there are a bunch of inline functions in FileSystem.h that could theoretically be refactored in the future without remembering to trigger a violation (most of them call a non-inline version that you have a sandbox call in, some call fs::status directly).
Contributor
Author
There was a problem hiding this comment.
That's true, my approach isn't bulletproof either. Would you prefer if we only triggered sandbox violations the core low-level functions and left stuff like is_other() alone? I don't have a strong preference here.
Collaborator
There was a problem hiding this comment.
That's my weak preference, but I won't block the PR over this if anyone disagrees. It is a (tiny) perf win to only check it once, but I doubt it matters.
benlangmuir
approved these changes
Dec 11, 2025
Collaborator
benlangmuir
left a comment
benlangmuir
left a comment
There was a problem hiding this comment.
LGTM other than changing the default value of LLVM_ENABLE_IO_SANDBOX.
jansvoboda11
force-pushed
the
sandboxing-v2
branch
from
3a5a95c to
7c3ba74
Compare
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/27/builds/20216 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/110/builds/6756 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/169/builds/17937 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/95/builds/19412 Here is the relevant piece of the build log for the reference |
This was referenced Dec 17, 2025
jansvoboda11
added a commit
that referenced
this pull request
Dec 19, 2025
Reverts #171935. The sandbox infrastructure was (incorrectly) only implemented for `clang -cc1` jobs created by the driver in #165350. Direct `clang -cc1` invocations had the sandbox disabled. This reduced the coverage of our test suite and lead to sandbox violations for people using asserts-enabled Clang. This PR temporarily disables the sandbox for asserts builds, so that we have time to investigate and fix sandbox violations for direct `clang -cc1` commands and re-enable for asserts builds at a later time.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Dec 19, 2025
… (#173074) Reverts llvm/llvm-project#171935. The sandbox infrastructure was (incorrectly) only implemented for `clang -cc1` jobs created by the driver in llvm/llvm-project#165350. Direct `clang -cc1` invocations had the sandbox disabled. This reduced the coverage of our test suite and lead to sandbox violations for people using asserts-enabled Clang. This PR temporarily disables the sandbox for asserts builds, so that we have time to investigate and fix sandbox violations for direct `clang -cc1` commands and re-enable for asserts builds at a later time.
Priyanshu3820
pushed a commit
to Priyanshu3820/llvm-project
that referenced
this pull request
Dec 20, 2025
This PR introduces a new mechanism for enforcing a sandbox around filesystem reads coming from the compiler. A fatal error is raised whenever the `llvm::sys::fs`, `llvm::MemoryBuffer::getFile*()` APIs get used directly instead of going through the "blessed" virtual interface of `llvm::vfs::FileSystem`.
valadaptive
pushed a commit
to valadaptive/llvm-project
that referenced
this pull request
Dec 24, 2025
Reverts llvm#171935. The sandbox infrastructure was (incorrectly) only implemented for `clang -cc1` jobs created by the driver in llvm#165350. Direct `clang -cc1` invocations had the sandbox disabled. This reduced the coverage of our test suite and lead to sandbox violations for people using asserts-enabled Clang. This PR temporarily disables the sandbox for asserts builds, so that we have time to investigate and fix sandbox violations for direct `clang -cc1` commands and re-enable for asserts builds at a later time.
mahesh-attarde
pushed a commit
to mahesh-attarde/llvm-project
that referenced
this pull request
Jan 6, 2026
Reverts llvm#171935. The sandbox infrastructure was (incorrectly) only implemented for `clang -cc1` jobs created by the driver in llvm#165350. Direct `clang -cc1` invocations had the sandbox disabled. This reduced the coverage of our test suite and lead to sandbox violations for people using asserts-enabled Clang. This PR temporarily disables the sandbox for asserts builds, so that we have time to investigate and fix sandbox violations for direct `clang -cc1` commands and re-enable for asserts builds at a later time.
jansvoboda11
added a commit
that referenced
this pull request
Jan 7, 2026
This PR enables the FS sandbox for direct `clang -cc1` invocations. #165350 unintentionally implemented the sandbox only for the code path where `clang -cc1` gets invoked after being expanded from a driver command line, which reduced the expected test coverage.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jan 7, 2026
…ns (#174653) This PR enables the FS sandbox for direct `clang -cc1` invocations. llvm/llvm-project#165350 unintentionally implemented the sandbox only for the code path where `clang -cc1` gets invoked after being expanded from a driver command line, which reduced the expected test coverage.
navaneethshan
pushed a commit
to qualcomm/cpullvm-toolchain
that referenced
this pull request
Jan 8, 2026
This PR enables the FS sandbox for direct `clang -cc1` invocations. llvm/llvm-project#165350 unintentionally implemented the sandbox only for the code path where `clang -cc1` gets invoked after being expanded from a driver command line, which reduced the expected test coverage.
kshitijvp
pushed a commit
to kshitijvp/llvm-project
that referenced
this pull request
Jan 9, 2026
…4653) This PR enables the FS sandbox for direct `clang -cc1` invocations. llvm#165350 unintentionally implemented the sandbox only for the code path where `clang -cc1` gets invoked after being expanded from a driver command line, which reduced the expected test coverage.
navaneethshan
pushed a commit
to qualcomm/cpullvm-toolchain
that referenced
this pull request
Jan 9, 2026
Reverts llvm/llvm-project#171935. The sandbox infrastructure was (incorrectly) only implemented for `clang -cc1` jobs created by the driver in llvm/llvm-project#165350. Direct `clang -cc1` invocations had the sandbox disabled. This reduced the coverage of our test suite and lead to sandbox violations for people using asserts-enabled Clang. This PR temporarily disables the sandbox for asserts builds, so that we have time to investigate and fix sandbox violations for direct `clang -cc1` commands and re-enable for asserts builds at a later time. (cherry picked from commit 56c0173)
navaneethshan
pushed a commit
to qualcomm/cpullvm-toolchain
that referenced
this pull request
Jan 9, 2026
This PR enables the FS sandbox for direct `clang -cc1` invocations. llvm/llvm-project#165350 unintentionally implemented the sandbox only for the code path where `clang -cc1` gets invoked after being expanded from a driver command line, which reduced the expected test coverage. (cherry picked from commit 3911c6a)
Priyanshu3820
pushed a commit
to Priyanshu3820/llvm-project
that referenced
this pull request
Jan 18, 2026
…4653) This PR enables the FS sandbox for direct `clang -cc1` invocations. llvm#165350 unintentionally implemented the sandbox only for the code path where `clang -cc1` gets invoked after being expanded from a driver command line, which reduced the expected test coverage.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces a new mechanism for enforcing a sandbox around filesystem reads coming from the compiler. A fatal error is raised whenever the
llvm::sys::fs,llvm::MemoryBuffer::getFile*()APIs get used directly instead of going through the "blessed" virtual interface ofllvm::vfs::FileSystem.