Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How safe is Zig?

scattered-thoughts.net

Post reply on HN
Print view View original

51–60 of 259 posts

Re: How safe is Zig?

#51

Post by nine_k »

snicker7 wrote: post #46
verdagon wrote: post #17

A lot of embedded devices and safety critical software sometimes don't even use a heap, and instead use pre-allocated chunks of memory whose size is calculated beforehand. It's memory safe, and has much more deterministic execution time. This is also a popular approach in games, especially ones with entity-component-system architectures. I'm excited about Zig for these use cases especially, it can be a much easier ap…

How exactly is pre-allocation safer? If you would ever like to re-use chunks of memory, then wouldn’t you still encounter “use-after-free” bugs?

No; every chunk is for single, pre-determined use.

Imagine all variables in your program declared as static. This includes all buffers (with indexes instead of pointers), all nested structures, etc.

Re: How safe is Zig?

#52

Post by uecker »

hyperpape wrote: post #10
ArrayBoundCheck wrote: post #3

I like zig but this is taking a page out of rust book and exaggerating C and C++ clang and gcc will both tell you at runtime if you go out of bounds, have an integer overflow, use after free etc. You need to turn on the sanitizer. You can't have them all on at the same time because code will be unnecessarily slow (ex: having thread sanitizer on in a single threaded app is pointless)

Can you explain why, in spite of the fact that (according to you) C & C++ aren't that unsafe, critical projects like Chromium can't get this right? https://twitter.com/pcwalton/status/1539112080590217217 Is the Project Zero team just too lazy to remind Chromium to use sanitizers?

I think the big question is, whether two teams writing software on a fixed budget using Rust or C using modern tools and best practices would end up with a safer product. I think this is not clear at all.

Re: How safe is Zig?

#53

Post by uecker »

uecker wrote: post #52
hyperpape wrote: post #10

Earlier quoted context omitted.

Can you explain why, in spite of the fact that (according to you) C & C++ aren't that unsafe, critical projects like Chromium can't get this right? https://twitter.com/pcwalton/status/1539112080590217217 Is the Project Zero team just too lazy to remind Chromium to use sanitizers?

I think the big question is, whether two teams writing software on a fixed budget using Rust or C using modern tools and best practices would end up with a safer product. I think this is not clear at all.

(Ok, I should read the text before sending.)

Re: How safe is Zig?

#54

Post by klyrs »

ajross wrote: post #48

> In practice, it doesn't seem that any level of testing is sufficient to prevent vulnerabilities due to memory safety in large programs. So I'm not covering tools like AddressSanitizer that are intended for testing and are not recommended for production use. I closed the window right there. Digs like this (the "not recommended" bit is a link to a now famous bomb thrown by Szabolcs on the oss-sec list, not to any kin…

As a Zig fan, I disagree. I think it's really important to examine the toolchain that beginners are going to use.

> I'm also focusing on software as it is typically shipped, ignoring eg bounds checking compilers like tcc or quarantining allocators like hardened_malloc which are rarely used because of the performance overhead.

To advertize that Zig is perfectly safe because things like ASan exist would be misleading, because that's not what users get out of the box. Zig is up-front and honest about the tradeoffs between safety and performance, and this evaluation of Zig doesn't give any surprises if you're familiar with how Zig describes itself.

Re: How safe is Zig?

#55

Post by Snarwin »

jewpfko wrote: post #18
dleslie wrote: post #2

And here is the table with Nim added; though potentially many GC'd languages would be similar to Nim: https://uploads.peterme.net/nimsafe.html Edit: noteworthy addendum: the ARC/ORC features have been released, so the footnote is now moot.

Thanks! I'd love to see a Dlang BetterC column too

Here's a version with D included:

https://gist.github.com/pbackus/0e9c9d0c83cd7d3a46365c054129...

The only difference in BetterC is that you lose access to the GC, so you have to use RC if you want safe heap allocation.

Re: How safe is Zig?

#56

Post by pron »

lmh wrote: post #34

Question for Zig experts: Is it possible, in principle, to use comptime to obtain Rust-like safety? If this was a library, could it be extended to provide even stronger guarantees at compile time, as in a dependent type system used for formal verification? Of course, this does not preclude a similar approach in Rust or C++ or other languages; but comptime's simplicity and generality seem like they might be beneficial…

Not as it is (it would require mutating the type's "state"), but hypothetically, comptime could be made to support even more programmable types. But could doesn't mean should. Zig values language simplicity and explicitness above many other things.

Re: How safe is Zig?

#57

Post by anonymoushn »

lmh wrote: post #34

Question for Zig experts: Is it possible, in principle, to use comptime to obtain Rust-like safety? If this was a library, could it be extended to provide even stronger guarantees at compile time, as in a dependent type system used for formal verification? Of course, this does not preclude a similar approach in Rust or C++ or other languages; but comptime's simplicity and generality seem like they might be beneficial…

It is possible in principle to write a Rust compiler in comptime Zig, but the real answer is "no."

Re: How safe is Zig?

#58

Post by alphazino »

anonymoushn wrote: post #12

I would like Zig to do more to protect users from dangling stack pointers somehow. I am almost entirely done writing such bugs, but I catch them in code review frequently, and I recently moved these lines out of main() into some subroutine: var fba = std.heap.FixedBufferAllocator.init(slice_for_fba); gpa = fba.allocator(); slice_for_fba is a heap-allocated byte slice. gpa is a global. fba was local to main(), which c…

> so they would be avoided if we had non-movable/non-copyable types.

There is a proposal for this that was accepted a while ago[0]. However, the devs have been focused on the self-hosted compiler recently, so they're behind on actually implementing accepted proposals.

[0] https://github.com/ziglang/zig/issues/7769

Re: How safe is Zig?

#59

Post by anonymoushn »

woodruffw wrote: post #26
AlotOfReading wrote: post #20

Earlier quoted context omitted.

State of the art sanitizing is pretty consistently in the Yes, the "just-enable-the-compiler-flags" approach can be expensive, but the tools exist to allow most people to be sanitizing most of the time. Devs simply don't know what's available to them.

I'd consider even 10% to be a significant performance hit. People scream bloody murder when CPU-level mitigations cause even 1-2% regressions. The marginal cost of mitigations when memory safe code can run without them is infinite. But let's say, for the sake of argument, that I can tolerate programs that run twice as long in production. This doesn't improve much: * I'm not going to be deploying SoTA sanitizers (SANR…

> People scream bloody murder when CPU-level mitigations cause even 1-2% regressions

For a particular simulation on a particular Cascade Lake chip, mitigations collectively cause it to run about 30% slower. So I won't scream about 1%, but that's a lot of 1%s.

Re: How safe is Zig?

#60

Post by tptacek »

_vvhw wrote: post #50
tptacek wrote: post #39

"Temporal" and "spatial" is a good way to break this down, but it might be helpful to know the subtext that, among the temporal vulnerabilities, UAF and, to an extent, type confusion are the big scary ones. Race conditions are a big ugly can of worms whose exploitability could probably be the basis for a long, tedious debate. When people talk about Zig being unsafe, they're mostly reacting to the fact that UAFs are s…

I see your UAF and raise you a bleed! As you know, buffer bleeds like Heartbleed and Cloudbleed can happen even in a memory safe language, they're hard to defend against (padding is everywhere in most formats!), easier to pull off than a UAF, often remotely accessible, difficult to detect, remain latent for a long time, and the impact is devastating. All your RAM are belong to us. For me, this can of worms is the one…

Has an exploitable buffer bleed (I'm happy with this coinage!) happened in any recent memory safe codebase?
Post reply on HN