Hacker News Reader

Comment by landr0id | Hacker News Reader

>ReleaseSafe catches use-after-free errors through runtime checks which panic if the program tries to use freed memory.

I don't know Zig so maybe they know something I don't, but I have seen no evidence that it catches any type of use-after-free including double-free?

While writing a blog post (below) I went through the documentation to figure out the possible runtime memory safety checks Zig can insert. The term "use-after-free" or "UaF" never occurs on that documentation page. Searching for "safety-checked" doesn't yield any related hits either.

Unless maybe they're using the DebugAllocator in release builds? Even that does not reliably surface UaF.

https://landaire.net/memory-safety-by-default-is-non-negotia...

View on HN

I as someone with writing Zig a bunch, can safely say if it does it hasn't even worked for me.

I am talking from experience from a pre-ai human mitts writing code perspective maybe Zig + LLMs do some magic.

The more I read the article the more I feel like this is just bad not sure if I should be giving it as much latitude as I have been in my prior comments.

There are other claims as well that are weirdly phrased at least.

Reads like an article written to justify some arguments they had rather than a genuine take at this point.

But I will give the benefit of doubt I enjoy weird articles, languages and share a dislike for aggressive AI-ness of all things.

I believe you are correct.

I think ReleaseSafe just adds bound checking and panics on unreachable code.

I don't think Zig offers any temporal memory safety.

The DebugAllocator catches use-after-free (at least on page-level), but at the cost of never recycling memory addresses (e.g. it eats through the virtual address space).

https://ziglang.org/documentation/master/std/#src/std/heap/d...

For higher level code, "generation-counted index handles" might be the better solution to provide temporal runtime memory safety, not part of Zig the stdlib though.

Or even better: never use dynamic memory allocation and make all lifetimes 'static' :)

>The DebugAllocator catches use-after-free (at least on page-level)

To clarify, is that to say that you have to use the `std.heap.page_allocator` as its backing allocator?

as a reminder its a construct in the zig stdlib to take an arbitrary chunk of memory (could be stack, could be in the programs static space) and wrap it in an allocator interface and give that to any data structure that needs an allocator and use it as if it were just malloc/free, with a fixed memory limit and the correct memory errors.

I don't know enough about Zig to explain it, but there is more to ReleaseSafe than checks and panics. ReleaseSafe also clears memory that no longer has an owner (I might be describing that wrong, that is just how I understand it). I found this out with a rendering issue recently.

The bug was around passing a slice to OpenGL which referenced memory outside of its lifetime. Since the memory location had no owner, vertices would still exist in Dev builds and everything would work fine, but in ReleaseSafe the application would run and just have nothing to render.

Since OpenGL was trying to read the memory, there was no panic from Zig, but it was a cool look into how the different build modes handle memory.

This is the commit where I fixed the issue: https://github.com/quot/donut/commit/8fff107e76278c4bf55007c...

Zig does offer some amount of temporal memory safety.

Link: 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-5284...

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/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.

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

(Also similar to when you use indexes to an array in Rust and happen to read from a wrong but in-bounds index.)

Reply on news.ycombinator.com