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

61–70 of 259 posts

Re: How safe is Zig?

#61

Post by jerf »

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?

While I'm generally in favor of the proposition that C++ is an intrinsically dangerous language, pointing at one of the largest possible projects that uses it isn't the best argument. If I pushed a button and magically for free Chrome was suddenly in 100% pure immaculate Rust, I'm sure it would still have many issues and problems that few other projects would have, just due to its sheer scale. I would still consider it an open question/problem as to whether Rust can scale up to that size and still be something that humans can modify. I could make a solid case that the difficulty of working in Rust would very accurately reflect a true and essential difficulty of working at that scale in general, but it could still be a problem.

(Also Rust defenders please note I'm not saying Rust can't work at that scale. I'm just saying, it's a very big scale and I think it's an open problem. My personal opinion and gut say yes, it shouldn't be any worse than it has to be because of the sheer size (that is, the essential complexity is pretty significant no matter what you do), but I don't know that.)

Re: How safe is Zig?

#62

Post by ajross »

klyrs wrote: post #54
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,…

> To advertize that Zig is perfectly safe because things like ASan exist would be misleading

Exactly! And for the same reason. You frame your comparison within the bounds of techniques that are used in practice. You don't refuse to compare a tool ahead of time, especially when doing so reinforces your priors.

To be blunt: ASan is great. ASan finds bugs. Everyone should use ASan. Everyone should advocate for ASan. But doing that cuts against the point the author is making (which is basically the same maximalist Rust screed we've all heard again and again), so... he skipped it. That's not good faith comparison, it's spin.

Re: How safe is Zig?

#63

Post by olig15 »

verdagon wrote: post #49
snicker7 wrote: post #46

Earlier quoted context omitted.

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?

The approach can reuse old elements for new instances of the same type, so to speak. Since the types are the same, any use-after-free becomes a plain ol' logic error. We use this approach in Rust a lot, with Vecs.

But if you have a structure that contains offsets into another buffer somewhere, or an index, whatever - the wrong value here could be just as bad as a use-after-free. I don’t see how this is any safer. If you use memory after free from a malloc, with any chance you’ll hit a page fault, and your app will crash. If you have a index/pointer to another structure, you could still end up reading past the end of that structure into the unknown.

Re: How safe is Zig?

#64

Post by _vvhw »

tptacek wrote: post #60
_vvhw wrote: post #50

Earlier quoted context omitted.

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?

I worked on a static analysis tool to detect bleeds in outgoing email attachments, looking for non-zero padding in the ZIP file format.

It caught different banking/investment systems written in memory safe languages leaking server RAM. You could sometimes see the whole intranet web page, that the teller or broker used to generate and send the statement, leaking through.

Bleeds terrify me, no matter the language. The thing with bleeds is that they're as simple as a buffer underflow, or forgetting to zero padding. Not even the borrow checker can provide safety against that.

Re: How safe is Zig?

#65

Post by KerrAvon »

ajross wrote: post #62
klyrs wrote: post #54

Earlier quoted context omitted.

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,…

> To advertize that Zig is perfectly safe because things like ASan exist would be misleading Exactly! And for the same reason. You frame your comparison within the bounds of techniques that are used in practice. You don't refuse to compare a tool ahead of time, especially when doing so reinforces your priors. To be blunt: ASan is great. ASan finds bugs. Everyone should use ASan. Everyone should advocate for ASan. But…

ASAN doesn’t add memory safety to the base language. It catches problems during testing, assuming those problems occur during the testing run (they don’t always! ASAN is not a panacea!). It’s perfectly fair to rule it out of bounds for this sort of comparison.

Re: How safe is Zig?

#66

Post by pcwalton »

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.

People have done just that with, for example, Firefox components and found that yes, Rust gives you a safer product.

Re: How safe is Zig?

#67

Post by pcwalton »

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…

Even in this environment, you can still have dangling pointers to freed stack frames. There's no way around having a proper lifetime system, or a GC, if you want memory safety.

Re: How safe is Zig?

#68

Post by tptacek »

_vvhw wrote: post #64
tptacek wrote: post #60

Earlier quoted context omitted.

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

I worked on a static analysis tool to detect bleeds in outgoing email attachments, looking for non-zero padding in the ZIP file format. It caught different banking/investment systems written in memory safe languages leaking server RAM. You could sometimes see the whole intranet web page, that the teller or broker used to generate and send the statement, leaking through. Bleeds terrify me, no matter the language. The…

You have my attention!

Re: How safe is Zig?

#69

Post by verdagon »

olig15 wrote: post #63
verdagon wrote: post #49

Earlier quoted context omitted.

The approach can reuse old elements for new instances of the same type, so to speak. Since the types are the same, any use-after-free becomes a plain ol' logic error. We use this approach in Rust a lot, with Vecs.

But if you have a structure that contains offsets into another buffer somewhere, or an index, whatever - the wrong value here could be just as bad as a use-after-free. I don’t see how this is any safer. If you use memory after free from a malloc, with any chance you’ll hit a page fault, and your app will crash. If you have a index/pointer to another structure, you could still end up reading past the end of that struc…

That's just a logic error, and not memory unsafety which might risk UB or vulnerabilities. The type system enforces that if we use-after-"free" (remember, we're not free'ing or malloc'ing), we just get a different instance of the same type, which is memory-safe.

You do bring up a valid broader concern. Ironically, this is a reason that GC'd systems can sometimes be better for privacy than Ada or Rust which uses a lot more Vec+indexes. An index into a Vec is riskier than a Java List; a Java reference can never suddenly point to another user account like an index could.

But that aside, we're talking about memory safety, array-centric approaches in Zig and Rust can be appropriate for a lot of use cases.

Re: How safe is Zig?

#70

Post by hyperpape »

jerf wrote: post #61
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?

While I'm generally in favor of the proposition that C++ is an intrinsically dangerous language, pointing at one of the largest possible projects that uses it isn't the best argument. If I pushed a button and magically for free Chrome was suddenly in 100% pure immaculate Rust, I'm sure it would still have many issues and problems that few other projects would have, just due to its sheer scale. I would still consider…

You're right that Chromium* is a very difficult task, but I disagree with the conclusion you draw. I think Chromium is one of the best examples we can consider.

There would absolutely be issues, including security issues. But there is also very good evidence that the issues that are most exploited in browsers and operating systems relate to memory safety. Alex Gaynor's piece that the author linked is good on this point.

While securing Chromium is huge and a difficult task, it and consumer operating systems are crucial for individual security. Until browsers and consumer operating systems are secure, individuals ranging from persecuted political dissidents to Jeff Bezos won't be secure.

* Actually not sure why I said Chromium rather than Chrome. Nothing hangs on the distinction, afaict.

Post reply on HN