-
Notifications
You must be signed in to change notification settings - Fork 200
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[LibOS,PAL] Emulate file-backed mmap via PAL read/write APIs
Previously, the `chroot` FS (plain host-backed files) used the `PalStreamMap()` PAL API for file-backed mmap. This had three problems: 1) need to implement a non-trivial `map` callback in PALs; 2) discrepancy between `map` implementations in different PALs; 3) hard to debug file-mmap bugs because they only reproduced on SGX (`gramine-sgx`) PAL and not on Linux (`gramine-direct`) PAL. Note that other FSes already used emulated file-backed mmap: `tmpfs` and `encrypted` FSes emulate such mmaps via `PalStreamRead()` and `PalStreamWrite()`. This commit switches `chroot` FS to use emulated file-backed mmap. This way, `chroot` becomes similar in implementation to `tmpfs` and `encrypted` FSes. Only `shm` FS still uses `PalDeviceMap()` (previously called `PalStreamMap()`) because devices with shared memory have non-standard semantics of mmaps. Corresponding `file_map()` functions in PAL are removed. In this commit, we also introduce the model of "logical" split within a single VMA: some prefix of the VMA is accessible (has valid pages), while the rest is unmapped (returns SIGBUS). Only file-backed VMAs are split in this way (anonymous-memory VMAs can't be in "unmapped" state). This logical split is achieved via a new `vma->valid_length` field. The switch to emulated mmap uncovered several bugs: - Underlying file may be shorter than the requested mmap size. In this case access beyond the last file-backed page must cause SIGBUS. Previously this semantics worked only on `gramine-direct` and wasn't implemented on `gramine-sgx` (even with EDMM). - As a consequence of the semantics above, file-growing `write()` and `ftruncate()` on already-mmapped file must make newly extended file contents accessible. Previously it didn't work on `gramine-sgx` (with EDMM), now it is resolved via `prot_refresh_mmaped_from_file_handle()` call. - `msync()` must update file contents with the mmapped-in-process contents, but only those parts that do not exceed the file size. Previously there was a bug that msync'ed even the exceeding parts. - Applications expect `msync(MS_ASYNC)` to update file contents before the next app access to the file. Gramine instead ignored such requests, leading to accessing stale contents. We fix this bug by treating `MS_ASYNC` the same way as `MS_SYNC`. This bug was detected on LTP test `msync01`. A few more FS tests are enabled on SGX now. Generally, `gramine-sgx` now supports shared file-backed mappings, i.e. `mmap(MAP_SHARED)`. New LibOS test `mmap_file_sigbus` is added; old bad `mmap_file` test is removed. Signed-off-by: Dmitrii Kuvaiskii <[email protected]>
- Loading branch information
Dmitrii Kuvaiskii
committed
Jul 29, 2024
1 parent
a173a4f
commit 4a5c4a1
Showing
35 changed files
with
682 additions
and
584 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.