11 ms·

Zig does offer some amount of temporal memory safety. Link: https://zig.guide/standard-library/allocators/ https://zig.guide/standard-library/allocators/ Text

by azakai 2mo ago

Zig does offer some amount of temporal memory safety. Link: https://zig.guide/standard-library/allocators/ https://zig.guide/standard-library/allocators/ Text: > The Zig standard library also has a general-purpose debug allocator. This is a safe allocator that can prevent double-free, use-after-free and can detect leaks. For more detail, see: https://github.com/ziglang/zig/issues/3180#issuecomment-528456706 https://github.com/ziglang/zig/issues/3180#issuecomment-5284...

landr0id 2mo ago
I still don't think that does anything regarding use-after-frees, only double-frees. Here's the code: https://codeberg.org/ziglang/zig/src/commit/e44e927d33d37c4417b9abb9a207b35fd25cd353/lib/std/heap/debug_allocator.zig https://codeberg.org/ziglang/zig/src/commit/e44e927d33d37c44... The closest callout in the doc comment is: >Never reuses memory addresses, making it easier for Zig to detect branch on undefined values in case of dangling pointers. This relies on the backing allocator to also not reuse addresses. But it's not really clear what this means. "branch on undefined values" would I think indicate that maybe they're doing a fill pattern that the compiler can detect at runtime when dereferenced? But I don't see it in the `free` path. It's not clear if this is deterministic or not either.
- azakai 2mo ago
  I'm not sure what "branch on undefined values" means there, yeah, but never reusing memory addresses is enough to prevent use-after-free. Or, rather, you can use a value after freeing it, but it will not be exploitable, because it will contain valid data of the right type. This is the same idea as Type-After-Type, https://dl.acm.org/doi/10.1145/3274694.3274705 https://dl.acm.org/doi/10.1145/3274694.3274705 (Also similar to when you use indexes to an array in Rust and happen to read from a wrong but in-bounds index.)

by azakai 2mo ago

landr0id 2mo ago

I still don't think that does anything regarding use-after-frees, only double-frees. Here's the code: https://codeberg.org/ziglang/zig/src/commit/e44e927d33d37c4417b9abb9a207b35fd25cd353/lib/std/heap/debug_allocator.zig https://codeberg.org/ziglang/zig/src/commit/e44e927d33d37c44... The closest callout in the doc comment is: >Never reuses memory addresses, making it easier for Zig to detect branch on undefined values in case of dangling pointers. This relies on the backing allocator to also not reuse addresses. But it's not really clear what this means. "branch on undefined values" would I think indicate that maybe they're doing a fill pattern that the compiler can detect at runtime when dereferenced? But I don't see it in the `free` path. It's not clear if this is deterministic or not either.

azakai 2mo ago
I'm not sure what "branch on undefined values" means there, yeah, but never reusing memory addresses is enough to prevent use-after-free. Or, rather, you can use a value after freeing it, but it will not be exploitable, because it will contain valid data of the right type. This is the same idea as Type-After-Type, https://dl.acm.org/doi/10.1145/3274694.3274705 https://dl.acm.org/doi/10.1145/3274694.3274705 (Also similar to when you use indexes to an array in Rust and happen to read from a wrong but in-bounds index.)