Released YYYY-MM-DD.
Released 2020-03-24.
When realloc
ing, 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 realloc
s, and can read the realoc
ed 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 MaybeUninit
s 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.
realloc
ing in-place when the pointer being realloc
ed 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.