Fix tracer pkey re-protection during init for libc compartment support#666
Merged
Fix tracer pkey re-protection during init for libc compartment support#666
Conversation
added 2 commits
February 10, 2026 10:20
When IA2_LIBC_COMPARTMENT is enabled, the custom glibc's __minimal_malloc protects its entire heap (including TLS blocks) with IA2_LDSO_PKEY (pkey 1). During IA2 initialization, protect_tls_pages must re-protect each compartment's TLS with the correct per-compartment pkey. The kernel handles this correctly via VMA splitting. The C policy check (is_op_permitted) already allows compartment 0 to pkey_mprotect any memory during init, but the Rust memory map tracking rejected it with overly strict monotonicity checks. This aligns the Rust checks with the C policy by relaxing them before init_finished, matching the existing pattern for regular mprotect. Also re-enable the sandbox for libc compartment tests now that the tracer supports the re-protection pattern.
The tracer now handles pkey re-protection during init, so there is no need to disable the sandbox for libc compartment tests. Also run loader_minimal_malloc without the sandbox since it reads /proc/self/smaps, which is blocked by landlock.
fw-immunant
approved these changes
Feb 10, 2026
Contributor
fw-immunant
left a comment
fw-immunant
left a comment
There was a problem hiding this comment.
CMake change needs cleanup, but otherwise looks good.
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
2 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.
Background
When
IA2_LIBC_COMPARTMENTis enabled, the custom glibc's__minimal_mallocprotects its entire heap (including TLS blocks) with pkey 1. During IA2 initialization,protect_tls_pagesre-protects each compartment's TLS with the correct per-compartment pkey. The kernel handles this correctly via VMA splitting, but the tracer's Rust memory map tracking rejected the operation with overly strict monotonicity checks.is_op_permittedintrack_memory_map.c): already allows compartment 0 topkey_mprotectany memory during initmemory_map_pkey_mprotect_regioninlib.rs): rejected it because the region was already owned by another pkey or alreadypkey_mprotect'dChanges
Relax the Rust monotonicity checks before
init_finished, matching the existing pattern for regularmprotect. During init:pkey_mprotecton the same regionowner_pkeyto the new pkey during initloader_minimal_mallocwithout the sandbox since it reads/proc/self/smaps, which is not allowed by landlock (the sandbox's filesystem walk skips/proc/selfbecause it is a symlink)