Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set mmapped files as readonly to prevent other processes from modifying it by accident #137025

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Feb 14, 2025

Unfortunately this only is a guarantee on windows.
Double-unfortunately I don't know what's gonna happen when rustc segfaults on windows and a file is locked. Possibly the file is now deadlocked.

Linux just locks file as a hint, so only tools that know about file locking will actually respect it, others will just access it.

I guess if we had some sort of story for volatile memory we could use that as we're only reading bytes out of it and not actually mapping data structures to that memory.

@oli-obk
Copy link
Contributor Author

oli-obk commented Feb 14, 2025

@bors try @rust-timer queue

@rustbot
Copy link
Collaborator

rustbot commented Feb 14, 2025

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 14, 2025
@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 14, 2025
@bors
Copy link
Contributor

bors commented Feb 14, 2025

⌛ Trying commit 57ff16e with merge 393b4c0...

bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 14, 2025
Lock mmapped files to at least get some safety out of it

Unfortunately this only is a guarantee on windows.
Double-unfortunately I don't know what's gonna happen when rustc segfaults on windows and a file is locked. Possibly the file is now deadlocked.

Linux just locks file as a hint, so only tools that know about file locking will actually respect it, others will just access it.

I guess if we had some sort of story for volatile memory we could use that as we're only reading bytes out of it and not actually mapping data structures to that memory.
@rust-log-analyzer

This comment has been minimized.

@ChrisDenton
Copy link
Member

On Windows:

If a process terminates with a portion of a file locked or closes a file that has outstanding locks, the locks are unlocked by the operating system. However, the time it takes for the operating system to unlock these locks depends upon available system resources. Therefore, it is recommended that your process explicitly unlock all files it has locked when it terminates. If this is not done, access to these files may be denied if the operating system has not yet unlocked them.

Though I would also add:

Locking a region of a file does not prevent reading or writing from a mapped file view.

@bors
Copy link
Contributor

bors commented Feb 14, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 14, 2025
@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Feb 14, 2025

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

@oli-obk
Copy link
Contributor Author

oli-obk commented Feb 14, 2025

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@bors
Copy link
Contributor

bors commented Feb 14, 2025

⌛ Trying commit 0db5406 with merge 91c5854...

bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 14, 2025
Lock mmapped files to at least get some safety out of it

Unfortunately this only is a guarantee on windows.
Double-unfortunately I don't know what's gonna happen when rustc segfaults on windows and a file is locked. Possibly the file is now deadlocked.

Linux just locks file as a hint, so only tools that know about file locking will actually respect it, others will just access it.

I guess if we had some sort of story for volatile memory we could use that as we're only reading bytes out of it and not actually mapping data structures to that memory.
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Feb 14, 2025

💔 Test failed - checks-actions

@the8472
Copy link
Member

the8472 commented Feb 14, 2025

The files we mmap are write-once. So couldn't we set them to readonly after creating them? That should be at least as good as locking since making them writable again would require another program going out of its way to bypass this, which isn't the case with advisory locks.

@bors
Copy link
Contributor

bors commented Feb 15, 2025

☔ The latest upstream changes (presumably #137046) made this pull request unmergeable. Please resolve the merge conflicts.

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Mar 11, 2025

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

@oli-obk oli-obk changed the title Lock mmapped files to at least get some safety out of it Set mmapped files as readonly to prevent other processes from modifying it by accident Mar 11, 2025
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-18 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
#19 exporting to docker image format
#19 sending tarball 20.1s done
#19 DONE 23.9s
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-18]
[CI_JOB_NAME=x86_64-gnu-llvm-18]
debug: `DISABLE_CI_RUSTC_IF_INCOMPATIBLE` configured.
---
sccache: Listening on address 127.0.0.1:4226
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-18', '--enable-llvm-link-shared', '--set', 'rust.randomize-layout=true', '--set', 'rust.thin-lto-import-instr-limit=10', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--set', 'rust.lld=false', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--enable-new-symbol-mangling']
configure: build.build          := x86_64-unknown-linux-gnu
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-18/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.randomize-layout := True
configure: rust.thin-lto-import-instr-limit := 10
---
   Compiling rustc_builtin_macros v0.0.0 (/checkout/compiler/rustc_builtin_macros)
error: unnecessary `unsafe` block
    --> compiler/rustc_metadata/src/rmeta/encoder.rs:2251:20
     |
2251 |         let mmap = unsafe { Some(Mmap::map(path)?) };
     |                    ^^^^^^ unnecessary `unsafe` block
     |
     = note: `-D unused-unsafe` implied by `-D warnings`
     = help: to override `-D warnings` add `#[allow(unused_unsafe)]`

error: unnecessary `unsafe` block
   --> compiler/rustc_metadata/src/locator.rs:825:24
    |
825 |             let mmap = unsafe { Mmap::map(filename) };
    |                        ^^^^^^ unnecessary `unsafe` block

error: could not compile `rustc_metadata` (lib) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
Build completed unsuccessfully in 0:02:15

/// The given file must not be mutated (i.e., not written, not truncated, ...) until the mapping is closed.
///
/// However in practice most callers do not ensure this, so uses of this function are likely unsound.
/// This process must not modify nor remove the backing file while the memory map lives.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would removing the file be a problem? Mappings should say valid for unlinked files... unless network filesystems are involved I guess...

/// Someone may truncate our file, but then we'll SIGBUS, which is not great, but at least
/// we won't succeed with corrupted data.
///
/// To get a bit more hardening out of this we will set the file as readonly before opening it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't we immediately set it to readonly after initial creation? The writing process can have an FD with write permission and then make the file readonly that other processes can't open it for writing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. That disconnects the read only setting from the mmap. I guess I could check I'd it's already read only

@klensy
Copy link
Contributor

klensy commented Mar 11, 2025

Btw, memmap2 currently used is super outdated (0.2.3), https://github.com/RazrFalcon/memmap2-rs/blob/v0.9.5/CHANGELOG.md, maybe bump it? Need to review changelog, as there was a lot of changes.

@the8472
Copy link
Member

the8472 commented Mar 11, 2025

I think the linux CI containers run as root, so we probably should drop CAP_DAC_OVERRIDE to make sure that the permissions don't get bypassed.
OTOH macos and windows builds aren't affected by this so they would catch writes that shouldn't happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-perf Status: Waiting on a perf run to be completed. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants