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

101–110 of 259 posts

Re: How safe is Zig?

#101

Post by ArrayBoundCheck »

xedrac wrote: post #9
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)

> So I'm not covering tools like AddressSanitizer that are intended for testing and are not recommended for production use. How is it an exaggeration when he explicitly called this out?

ASAN isn't just "for testing". A lot of people went straight to the chart (like me) and it reeks of bullshit. double free is the same as use after free, null pointer dereference is essentially the same as type confusion since a nullable pointer is confused with a non null pointer, invalid stack read/write is the same as array out of bounds (or invalid pointers), etc

I also never heard of a data race existing without a race condition existing. That's a pointless metric like many of the above I mentioned

Re: How safe is Zig?

#102

Post by woodruffw »

_vvhw wrote: post #94
woodruffw wrote: post #91

Earlier quoted context omitted.

> For example, another way to think of this is that you have a buffer of initialized memory (no unsafe), containing a view onto some piece of data, from which you serve a subset to the user, but you get the format of the subset wrong, so that parts of the view leak through. That's a bleed. If there's full initialization then this is just a logic error, no? Apart from some kind of capability typing over ranges of byte…

Yes, exactly. That's what I was driving at. It's just a logic error, that leaks sensitive information, by virtue of leaking the wrong information. File formats in particular can make this difficult to get right. For example, the ZIP file format (that I have at least some experience with bleeds in) has at least 9 different places where a bleed might happen, and this can depend on things like: whether files are added i…

Makes sense! My colleagues work on some research[1] that's intended to be the counterpart to this: identifying which subset of a format parser is actually activated by a corpus of inputs, and automatically generating a subset parser that only accepts those inputs.

I think you mentioned WUFFS before the edit; I find that approach very promising!

[1]: https://www.darpa.mil/program/safe-documents

Re: How safe is Zig?

#103

Post by IshKebab »

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.

I don't know why Rust gets "runtime" and Nim gets "compile time" for type confusion?

Re: How safe is Zig?

#104

Post by verdagon »

com2kid wrote: post #96
verdagon wrote: post #85

Earlier quoted context omitted.

Yep, or generational references [0] which also protect against that kind of thing ;) The array-centric approach is indeed more applicable at the high levels of the program. Sometimes I wonder if a language could use an array-centric approach at the high levels, and then an arena-based approach for all temporary memory. Elucent experimented with something like this for Basil once [1] which was fascinating. [0] https:/…

> Yep, or generational references [0] which also protect against that kind of thing ;) First off, thank you for posting all your great articles on Vale! Second off, I just read the generational references blog post for the 3rd time and now it makes complete sense, like stupid obvious why did I have problems understanding this before sense. (PS: The link to the benchmarks is dead :( ) I hope some of the novel ideas in…

Thank you! I just fixed the link, thanks for letting me know! And if any of my articles are ever confusing, feel welcome to swing by the discord or file an issue =)

I'm pretty excited about all the memory safety advances languages have made in the last few years. Zig is doing some really interesting things (see Andrew's thread above), D's new static analysis for zero-cost memory safety hit the front page yesterday, we're currently prototyping Vale's region borrow checker, and it feels like the space is really exploding. Good time to be alive!

Re: How safe is Zig?

#105

Post by ArrayBoundCheck »

hyperpape wrote: post #95
ArrayBoundCheck wrote: post #87

Earlier quoted context omitted.

Considering how much I got downvoted no I don't want to comment more about this. But I'll let you ponder why while using rust has you could get a use after free sometimes https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4572...

Here's the commit: https://github.com/jeromefroe/lru-rs/pull/121/commits/416a2d... . I don't think this does much for your initial claim. Take the most generous reading you can--Rust isn't any better at preventing UAF than C/C++. That doesn't make safe C/C++ a thing, it means that Rust isn't an appropriate solution.

You missed the point. Just like the author did when he disqualified all the C++ tools

Writing unsafe code and removing tools "because production" gets you unsafe code as shown in that rust cve

Re: How safe is Zig?

#106

Post by im3w1l »

pcwalton wrote: post #67
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.

Well if get rid of not just the heap, but the stack too... turn all variables into global ones, then it will be safe.

This means we lose thread safety and functions become non-reentrant (but easy to prove safe - make sure graph of A-calls-B is a acyclical).

Re: How safe is Zig?

#107

Post by ArrayBoundCheck »

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…

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

What people? and in my experience rust has always been much higher than 2% regression

Re: How safe is Zig?

#108

Post by skullt »

AndyKelley wrote: post #81

I have one trick up my sleeve for memory safety of locals. I'm looking forward to experimenting with it during an upcoming release cycle of Zig. However, this release cycle (0.10.0) is all about polishing the self-hosted compiler and shipping it. I'll be sure to make a blog post about it exploring the tradeoffs - it won't be a silver bullet - and I'm sure it will be a lively discussion. The idea is (1) escape analysi…

Does that not contradict the Zig principle of no hidden allocations?

Re: How safe is Zig?

#109

Post by pjmlp »

masklinn wrote: post #15
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)

> clang and gcc will both tell you at runtime if you go out of bounds [...] You can't have them all on at the same time because code will be unnecessarily slow Yeah, so clang and gcc don't actually tell you at runtime if you go out of bounds. How many program ship production binaries with asan or ubsan enabled, to say nothing of msan or tsan? Also you can't have them all on at the same time because they're not necess…

Quite a few subsystems on Android, but that is about it.

https://source.android.com/devices/tech/debug/hwasan

Re: How safe is Zig?

#110

Post by _vvhw »

woodruffw wrote: post #102
_vvhw wrote: post #94

Earlier quoted context omitted.

Yes, exactly. That's what I was driving at. It's just a logic error, that leaks sensitive information, by virtue of leaking the wrong information. File formats in particular can make this difficult to get right. For example, the ZIP file format (that I have at least some experience with bleeds in) has at least 9 different places where a bleed might happen, and this can depend on things like: whether files are added i…

Makes sense! My colleagues work on some research[1] that's intended to be the counterpart to this: identifying which subset of a format parser is actually activated by a corpus of inputs, and automatically generating a subset parser that only accepts those inputs. I think you mentioned WUFFS before the edit; I find that approach very promising! [1]: https://www.darpa.mil/program/safe-documents

Thanks! Yes, I did mention WUFFS before the edit, but then figured I could make it a bit more detailed. WUFFS is great.

The SafeDocs program and approach looks incredible. Installing tools like this at border gateways for SMTP servers, or as a front line defense before vulnerable AV engine parsers (as Pure is intended to be used), could make such a massive dent against malware and zero days.

Post reply on HN