Released YYYY-MM-DD.
Released 2020-03-24.
When reallocing, if we allocate new space, we need to copy the old allocation‘s bytes into the new space. There are old_size number of bytes in the old allocation, but we were accidentally copying new_size number of bytes, which could lead to copying bytes into the realloc’d space from past the chunk that we're bump allocating out of, from unknown memory.
If an attacker can cause reallocs, and can read the realoced data back, this could allow them to read things from other regions of memory that they shouldn't be able to. For example, if some crypto keys happened to live in memory right after a chunk we were bump allocating out of, this could allow the attacker to read the crypto keys.
Beyond just fixing the bug and adding a regression test, I've also taken two additional steps:
While we were already running the testsuite under valgrind in CI, because valgrind exits with the same code that the program did, if there are invalid reads/writes that happen not to trigger a segfault, the program can still exit OK and we will be none the wiser. I've enabled the --error-exitcode=1 flag for valgrind in CI so that tests eagerly fail in these scenarios.
I‘ve written a quickcheck test to exercise realloc. Without the bug fix in this patch, this quickcheck immediately triggers invalid reads when run under valgrind. We didn’t previously have quickchecks that exercised realloc beacuse realloc isn't publicly exposed directly, and instead can only be indirectly called. This new quickcheck test exercises realloc via bumpalo::collections::Vec::resize and bumpalo::collections::Vec::shrink_to_fit calls.
This bug was introduced in version 3.0.0.
See #69 for details.
Released 209-2-07.
bumpalo::collections::Vec::into_bump_slice_mut method to turn a bumpalo::collections::Vec<'bump, T> into a &'bump mut [T].Released 2020-01-07.
bumpalo::collections::format! macro did not used to accept a trailing comma like format!(in bump; "{}", 1,), but it does now.Released 2020-01-03.
bumpalo::collections::vec! macro did not used to accept a trailing comma like vec![in bump; 1, 2,], but it does now.Released 2019-12-27.
Bump::allocated_bytes diagnostic method for counting the total number of bytes a Bump has allocated.Released 2019-12-20.
Added Bump::alloc_str for copying string slices into a Bump.
Added Bump::alloc_slice_copy and Bump::alloc_slice_clone for copying or cloning slices into a Bump.
Added Bump::alloc_slice_fill_iter for allocating a slice in the Bump from an iterator.
Added Bump::alloc_slice_fill_copy and Bump::alloc_slice_fill_clone for creating slices of length n that are filled with copies or clones of an inital element.
Added Bump::alloc_slice_fill_default for creating slices of length n with the element type's default instance.
Added Bump::alloc_slice_fill_with for creating slices of length n whose elements are initialized with a function or closure.
Added Bump::iter_allocated_chunks as a replacement for the old Bump::each_allocated_chunk. The iter_allocated_chunks version returns an iterator, which is more idiomatic than its old, callback-taking counterpart. Additionally, iter_allocated_chunks exposes the chunks as MaybeUninits instead of slices, which makes it usable in more situations without triggering undefined behavior. See also the note about bump direction in the “changed” section; if you‘re iterating chunks, you’re likely affected by that change!
Added Bump::with_capacity so that you can pre-allocate a chunk with the requested space.
BREAKING: The direction we allocate within a chunk has changed. It used to be “upwards”, from low addresses within a chunk towards high addresses. It is now “downwards”, from high addresses towards lower addresses.
Additionally, the order in which we iterate over allocated chunks has changed! We used to iterate over chunks from oldest chunk to youngest chunk, and now we do the opposite: the youngest chunks are iterated over first, and the oldest chunks are iterated over last.
If you were using Bump::each_allocated_chunk to iterate over data that you had previously allocated, and you want to iterate in order of oldest-to-youngest allocation, you need to reverse the chunks iterator and also reverse the order in which you loop through the data within a chunk!
For example, if you had this code:
unsafe { bump.each_allocated_chunk(|chunk| { for byte in chunk { // Touch each byte in oldest-to-youngest allocation order... } }); }
It should become this code:
let mut chunks: Vec<_> = bump.iter_allocated_chunks().collect(); chunks.reverse(); for chunk in chunks { for byte in chunk.iter().rev() { let byte = unsafe { byte.assume_init() }; // Touch each byte in oldest-to-youngest allocation order... } }
The good news is that this change yielded a speed up in allocation throughput of 3-19%!
See https://github.com/fitzgen/bumpalo/pull/37 and https://fitzgeraldnick.com/2019/11/01/always-bump-downwards.html for details.
BREAKING: The collections cargo feature is no longer on by default. You must explicitly turn it on if you intend to use the bumpalo::collections module.
Bump::reset will now retain only the last allocated chunk (the biggest), rather than only the first allocated chunk (the smallest). This should enable Bump to better adapt to workload sizes and quickly reach a steady state where new chunks are not requested from the global allocator.
The Bump::each_allocated_chunk method is removed in favor of Bump::iter_allocated_chunks. Note that its safety requirements for reading from the allocated chunks are slightly different from the old each_allocated_chunk: only up to 16-byte alignment is supported now. If you allocate anything with greater alignment than that into the bump arena, there might be uninitilized padding inserted in the chunks, and therefore it is no longer safe to read them via MaybeUninit::assume_init. See also the note about bump direction in the “changed” section; if you‘re iterating chunks, you’re likely affected by that change!
The std cargo feature has been removed, since this crate is now always no-std.
Released 2019-08-19.
Send for Bump.Released 2019-07-01.
alloc_slice_copy and alloc_slice_clone methods that allocate space for slices and either copy (with bound T: Copy) or clone (with bound T: Clone) the provided slice's data into the newly allocated space.Released 2019-05-20.
Released 2019-05-17.
Default for Bump.Released 2019-04-19.
Released 2019-04-19.
reallocing in-place when the pointer being realloced is the last allocation made from the bump arena. This should speed up various String, Vec, and format! operations in many cases.Released 2019-03-26.
alloc_with method, that (usually) avoids stack-allocating the allocated value and then moving it into the bump arena. This avoids potential stack overflows in release mode when allocating very large objects, and also some memcpy calls. This is similar to the copyless crate. Read the alloc_with doc comments and the original issue proposing this API for more.Released 2019-03-18.
Released 2019-03-18.
Released 2019-03-15.
Released 2019-02-12.
into_bump_slice method on bumpalo::collections::Vec<T>.Released 2019-02-11.
BumpAllocSafe trait.Released 2019-01-15.
debug_assert! that had false positives.Released 2018-11-28.
collections module, which contains ports of std's collection types that are compatible with backing their storage in Bump arenas.