Skip to content

mrs: add paced free #2377

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

Open
wants to merge 6 commits into
base: dev
Choose a base branch
from
Open

mrs: add paced free #2377

wants to merge 6 commits into from

Conversation

brooksdavis
Copy link
Member

Add support for deferring free to the malloc path where we check if we should revoke. I've called the feature paced rather than deferred because I think we'll likely want to batch frees and only do them on some calls to malloc.

OFFLOAD_QUARANTINE was making everything hard to read so I removed it as we're unlikely to want to use it again.

This branch contains the changes in #2376, but does not depend on the functionality included there (it would probably conflict if you tried to rebase without those changes)

brooksdavis pushed a commit that referenced this pull request Apr 1, 2025
Libarchive 3.7.7

Security fixes:
 #2158 rpm: calculate huge header sizes correctly
 #2160 util: fix out of boundary access in mktemp functions
 #2168 uu: stop processing if lines are too long
 #2174 lzop: prevent integer overflow
 #2172 rar4: protect copy_from_lzss_window_to_unp() (CVE-2024-20696)
 #2175 unzip: unify EOF handling
 #2179 rar4: fix out of boundary access with large files
 #2203 rar4: fix OOB access with unicode filenames
 #2210 rar4: add boundary checks to rgb filter
 #2248 rar4: fix OOB in delta filter
 #2249 rar4: fix OOB in audio filter
 #2256 fix multiple vulnerabilities identified by SAST
 #2258 cpio: ignore out-of-range gid/uid/size/ino and harden AFIO parsing
 #2265 rar5: clear 'data ready' cache on window buffer reallocs
 #2269 rar4: fix CVE-2024-26256 (CVE-2024-26256)
 #2330 iso: be more cautious about parsing ISO-9660 timestamps
 #2343 tar: clean up linkpath between entries
 #2364 tar: don't crash on truncated tar archives
 #2366 gzip: prevent a hang when processing a malformed gzip inside a gzip
 #2377 tar: fix two leaks in tar header parsing

Important bugfixes:
 #2096 rar5: report encrypted entries
 #2150 xar: fix another infinite loop and expat error handling
 #2173 shar: check strdup return value
 #2161 lha: fix integer truncation on 32-bit systems
 #2338 tar: fix memory leaks when processing symlinks or parsing pax headers
 #2245 7zip: fix issue when skipping first file in 7zip archive that
       is a multiple of 65536 bytes
 #2252 7-zip: read/write symlink paths as UTF-8
 #2259 rar5: don't try to read rediculously long names
 #2290 ar: fix archive entries having no type
 #2360 tar: fix truncation of entry pathnames in specific archives

CVE:		CVE-2024-20696, CVE-2024-26256
PR:		282047 (exp-run)
MFC after:	1 week
@@ -378,15 +383,18 @@ static size_t max_allocated_size;
* Quarantine arenas for application threads. At any given time, one is in
* active use, and the others are being cleaned.
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment should probably be extended to explain why we need at least 3 arenas.

Copy link
Member

Choose a reason for hiding this comment

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

If it's helpful, feel free to steal some prose from the relevant CHERIoT-RTOS allocator source, where it does the same thing (I am pretty sure): https://github.com/CHERIoT-Platform/cheriot-rtos/blob/20b588dca8fcff4f6ccac229dfe342cd09d50f29/sdk/core/allocator/alloc.h#L872-L903

OFFLOAD_QUARANTINE depends on pthreads support and has been superceeded
by in-kernel async revocation support.  MRS_PINNED_CPUSET was
technically independent, but primairly supported benchmarking
OFFLOAD_QUARANTINE.
The rest of the block is also a bit sketchy, but is less obviously
wrong.
Yuecheng Wang reports that with jemalloc, the tccache gets flushed if
too many frees happen at once leading to poor malloc performance.  This
feature defers frees to the malloc path and frees a batch of N (16 by
default) pointers every N free calls (per-thread).

This primative implemenation does not take size into account
so likely has adverse cache effects if malloc's and free's aren't well
matched.

This functionality defaults to off and can be enabled with
_RUNTIME_PACED_FREE_ENABLE.  A _RUNTIME_PACED_FREE_DISABLE also exists
should the default change.  The batch size may be adjusted with
_RUNTIME_PACED_FREE_BATCH_SIZE update the compile time limit
MAX_FREE_BATCH_SIZE (256 currently).
The capability is always a redrived capability so we can safely use it's
size (and are doing so).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants