3 ms·

How close are Zig's safety guarantees to Rust's? Honest question; I don't follow Zig development. I can't take C seriously because it hasn't even bothered to de

How close are Zig's safety guarantees to Rust's? Honest question; I don't follow Zig development. I can't take C seriously because it hasn't even bothered to define provenance until now, but as far as I'm aware, Zig doesn't even try to touch these topics. Does Zig document the precise mechanics of noalias? Does it provide a mechanism for controllably exposing or not exposing provenance of a pointer? Does it specify the provenance ABA problem in atomics on compare-exchange somehow or is that undefined? Are there any plans to make allocation optimizations sound? (This is still a problem even in Rust land; you can write a program that is guaranteed to exhibit OOM according to the language spec, but LLVM outputs code that doesn't OOM.) Does it at least have a sanitizer like Miri to make sure UB (e.g. data races, type confusion, or aliasing problems) is absent? If the answer to most of the above is "Zig doesn't care", why do people even consider it better than C?

dnautics 1y ago
safety-wise, zig is better than C because if you don't do "easily flaggable things"[0] it doesn't have buffer overruns (including protection in the case of sentinel strings), or null pointer exceptions. Where this lies on the spectrum of "C to Rust" is a matter of judgement, but if I'm not mistaken it is easily a majority of memory-safety related CVEs. There's also no UB in debug, test, or release-safe. Note: you can opt-out of release-safe on a function-by-function basis. IIUC noalias is safety checked in debug, test, and release-safe. In a sibling comment, I mentioned a proof of concept I did that if I had the time to complete/do correctly, it should give you near-rust-level checking on memory safety, plus automatically flags sites where you need to inspect the code. At the point where you are using MIRI, you're already bringing extra stuff into rust, so in practice zig + zig-clr could be the equivalent of the result of "what if you moved borrow checking from rustc into miri" [0] type erasure, or using "known dangerous types, like c pointers, or non-slice multipointers".
- tialaramex 1y ago
  This is very much a "Draw the rest of the fucking owl" approach to safety.
  - dnautics 1y ago
    what percentage of CVEs are null pointer problems or buffer overflows? That's what percentage of the owl has been drawn. If someone (or me) builds out a proper zig-clr, then we get to, what? 90%. Great. Probably good enough, that's not far off from where rust is.
    - comex 1y ago
      Probably >50% of exploits these days target use-after-frees, not buffer overflows. I don’t have hard data though. As for null pointer problems, while they may result in CVEs, they’re a pretty minor security concern since they generally only result in denial of service. Edit 2: Here's some data: In an analysis by Google, the "most frequently exploited" vulnerability types for zero-day exploitation were use-after-free, command injection, and XSS [3]. Since command injection and XSS are not memory-unsafety vulnerabilities, that implies that use-after-frees are significantly more frequently exploited than other types of memory unsafety. Edit: Zig previously had a GeneralPurposeAllocator that prevented use-after-frees of heap allocations by never reusing addresses. But apparently, four months ago [1], GeneralPurposeAllocator was renamed to DebugAllocator and a comment was added saying that the safety features "require the allocator to be quite slow and wasteful". No explicit reasoning was given for this change, but it seems to me like a concession that applications need high performance generally shouldn't be using this type of allocator. In addition, it appears that use-after-free is not caught for stack allocations [2], or allocations from some other types of allocators. Note that almost the entire purpose of Rust's borrow checker is to prevent use-after-free. And the rest of its purpose is to prevent other issues that Zig also doesn't protect against: tagged-union type confusion and data races. [1] https://github.com/ziglang/zig/commit/cd99ab32294a3c22f09615c93d611593a2887cc3 https://github.com/ziglang/zig/commit/cd99ab32294a3c22f09615... [2] https://github.com/ziglang/zig/issues/3180 https://github.com/ziglang/zig/issues/3180. [3] https://cloud.google.com/blog/topics/threat-intelligence/2024-zero-day-trends https://cloud.google.com/blog/topics/threat-intelligence/202...
      - dnautics 1y ago
        yeah I don't think the GPA is really a great strategy for detecting UAF, but it was a good try. It basically creates a new virtual page for each allocation, so the kernel gets involved and ?I think? there is more indirection for any given pointer access. So you can imagine why it wasn't great. Anyways, I am optimistic that UAF can be prevented by static analysis: https://www.youtube.com/watch?v=ZY_Z-aGbYm8 https://www.youtube.com/watch?v=ZY_Z-aGbYm8 Note since this sort of technique interfaces with the compiler, unless the dependency is in a .so file, it will detect UAF in dependencies too, whether or not the dependency chooses to run the static analysis as part of their software quality control.

dnautics 1y ago

safety-wise, zig is better than C because if you don't do "easily flaggable things"[0] it doesn't have buffer overruns (including protection in the case of sentinel strings), or null pointer exceptions. Where this lies on the spectrum of "C to Rust" is a matter of judgement, but if I'm not mistaken it is easily a majority of memory-safety related CVEs. There's also no UB in debug, test, or release-safe. Note: you can opt-out of release-safe on a function-by-function basis. IIUC noalias is safety checked in debug, test, and release-safe. In a sibling comment, I mentioned a proof of concept I did that if I had the time to complete/do correctly, it should give you near-rust-level checking on memory safety, plus automatically flags sites where you need to inspect the code. At the point where you are using MIRI, you're already bringing extra stuff into rust, so in practice zig + zig-clr could be the equivalent of the result of "what if you moved borrow checking from rustc into miri" [0] type erasure, or using "known dangerous types, like c pointers, or non-slice multipointers".

tialaramex 1y ago
This is very much a "Draw the rest of the fucking owl" approach to safety.
- dnautics 1y ago
  what percentage of CVEs are null pointer problems or buffer overflows? That's what percentage of the owl has been drawn. If someone (or me) builds out a proper zig-clr, then we get to, what? 90%. Great. Probably good enough, that's not far off from where rust is.
  - comex 1y ago
    Probably >50% of exploits these days target use-after-frees, not buffer overflows. I don’t have hard data though. As for null pointer problems, while they may result in CVEs, they’re a pretty minor security concern since they generally only result in denial of service. Edit 2: Here's some data: In an analysis by Google, the "most frequently exploited" vulnerability types for zero-day exploitation were use-after-free, command injection, and XSS [3]. Since command injection and XSS are not memory-unsafety vulnerabilities, that implies that use-after-frees are significantly more frequently exploited than other types of memory unsafety. Edit: Zig previously had a GeneralPurposeAllocator that prevented use-after-frees of heap allocations by never reusing addresses. But apparently, four months ago [1], GeneralPurposeAllocator was renamed to DebugAllocator and a comment was added saying that the safety features "require the allocator to be quite slow and wasteful". No explicit reasoning was given for this change, but it seems to me like a concession that applications need high performance generally shouldn't be using this type of allocator. In addition, it appears that use-after-free is not caught for stack allocations [2], or allocations from some other types of allocators. Note that almost the entire purpose of Rust's borrow checker is to prevent use-after-free. And the rest of its purpose is to prevent other issues that Zig also doesn't protect against: tagged-union type confusion and data races. [1] https://github.com/ziglang/zig/commit/cd99ab32294a3c22f09615c93d611593a2887cc3 https://github.com/ziglang/zig/commit/cd99ab32294a3c22f09615... [2] https://github.com/ziglang/zig/issues/3180 https://github.com/ziglang/zig/issues/3180. [3] https://cloud.google.com/blog/topics/threat-intelligence/2024-zero-day-trends https://cloud.google.com/blog/topics/threat-intelligence/202...
    - dnautics 1y ago
      yeah I don't think the GPA is really a great strategy for detecting UAF, but it was a good try. It basically creates a new virtual page for each allocation, so the kernel gets involved and ?I think? there is more indirection for any given pointer access. So you can imagine why it wasn't great. Anyways, I am optimistic that UAF can be prevented by static analysis: https://www.youtube.com/watch?v=ZY_Z-aGbYm8 https://www.youtube.com/watch?v=ZY_Z-aGbYm8 Note since this sort of technique interfaces with the compiler, unless the dependency is in a .so file, it will detect UAF in dependencies too, whether or not the dependency chooses to run the static analysis as part of their software quality control.