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

91–100 of 259 posts

Re: How safe is Zig?

#91

Post by woodruffw »

_vvhw wrote: post #88
raphlinus wrote: post #74

Earlier quoted context omitted.

I am skeptical until I see the details, and strongly suspect you are dealing with a "safe-ish" language rather than one which has Rust-level guarantees. Uninitialized memory reads are undefined behavior in basically all memory models in the C tradition. In Rust it is not possible to make a reference to a slice containing uninitialized memory without unsafe (and the rules around this have tightened relatively recently…

Hackers exploit any avenue (and usually come in through the basement!), regardless of how skeptical we might be that they won't. They don't need the details, they'll figure it out. You give them a scrap and they'll get the rest. It's a different way of thinking that we're not used to, and don't understand unless we're exposed to it first-hand, e.g. through red-teaming. For example, another way to think of this is tha…

> 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 bytes (not very ergonomic), this would be a very difficult subtype of "bleed" to statically describe, much less prevent.

Re: How safe is Zig?

#92

Post by AlotOfReading »

KerrAvon wrote: post #77
AlotOfReading wrote: post #43

Earlier quoted context omitted.

I think we basically agree. Hypothetically ideal memory safety is strictly better, but sanitizers are better than nothing for code using fundamentally unsafe languages. My personal experience is that more people are dissuaded from sanitizer usage more by hypothetical (and manageable) issues like overhead than real implementation problems.

If you can afford a 10-50% across-the-board performance reduction, why would you not use a higher-level, actually safe language like Ruby or Python? Remember that the context of this article is Zig vs other languages, so the assumption is you’re writing new code.

I work in real time, often safety critical environments. High level interpreted languages aren't particularly useful there. The typical options are C/C++, hardware (e.g. FPGAs), or something more obscure like Ada/Spark.

But in general, sanitizers are also something you can do to legacy code to bring it closer to safety and you can turn them off for production if you absolutely, definitely need those last few percent (which few people do). It's hard to overstate how valuable all of that is. A big part of the appeal of zig is its interoperability with C and the ability to introduce it gradually. Compare to the horrible contortions you have to do with CFFI to call Python from C.

Re: How safe is Zig?

#93

Post by com2kid »

kaba0 wrote: post #90
com2kid wrote: post #29

Earlier quoted context omitted.

> Do compilers really can never call `free()`? I worked on, one of the many, Microsoft compiler teams, though as a software engineer in test not directly on the compiler itself, and I believe the lead dev told me they don't free any memory, though I could be misremembering since it was my first job out of college. Remember C compilers are often one file at a time (and a LOLWTF # of includes), and the majority of work…

Bootstrapping aside, a compiler written in a GCd language would make perfect sense. It really doesn’t have any reason to go lower level than that (other than of course, if one wants to bootstrap it in the same language that happens to be a low-level one)

There is no reason to free memory. Your process is going to hard exit after a set workload.

If you wrote a compiler in a GCd language, you'd want to disable the collector because that just takes time, and compilers are slow enough as it is!

Re: How safe is Zig?

#94

Post by _vvhw »

woodruffw wrote: post #91
_vvhw wrote: post #88

Earlier quoted context omitted.

Hackers exploit any avenue (and usually come in through the basement!), regardless of how skeptical we might be that they won't. They don't need the details, they'll figure it out. You give them a scrap and they'll get the rest. It's a different way of thinking that we're not used to, and don't understand unless we're exposed to it first-hand, e.g. through red-teaming. For example, another way to think of this is tha…

> 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 incrementally to the archive, the type of string encoding used for file names in the archive etc.

Re: How safe is Zig?

#95

Post by hyperpape »

ArrayBoundCheck wrote: post #87
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?

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.

Re: How safe is Zig?

#96

Post by com2kid »

verdagon wrote: post #85
pcwalton wrote: post #67

Earlier quoted context omitted.

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.

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 Vale make it out to the programming language world at large!

Re: How safe is Zig?

#97

Post by slowking2 »

KerrAvon wrote: post #77
AlotOfReading wrote: post #43

Earlier quoted context omitted.

I think we basically agree. Hypothetically ideal memory safety is strictly better, but sanitizers are better than nothing for code using fundamentally unsafe languages. My personal experience is that more people are dissuaded from sanitizer usage more by hypothetical (and manageable) issues like overhead than real implementation problems.

If you can afford a 10-50% across-the-board performance reduction, why would you not use a higher-level, actually safe language like Ruby or Python? Remember that the context of this article is Zig vs other languages, so the assumption is you’re writing new code.

Python is usually a lot more than a 50% reduction in performance. Sometimes you need better performance but not the best performance.

Re: How safe is Zig?

#98

Post by [deleted] »

pjmlp wrote: post #76
verdagon wrote: post #69

Earlier quoted context omitted.

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…

In high integrity computing that is pretty much safety related, if that logic error causes someone to die due to corrupt data, like using the wrong radiation value.

[deleted]

Re: How safe is Zig?

#99

Post by kaba0 »

com2kid wrote: post #93
kaba0 wrote: post #90

Earlier quoted context omitted.

Bootstrapping aside, a compiler written in a GCd language would make perfect sense. It really doesn’t have any reason to go lower level than that (other than of course, if one wants to bootstrap it in the same language that happens to be a low-level one)

There is no reason to free memory. Your process is going to hard exit after a set workload. If you wrote a compiler in a GCd language, you'd want to disable the collector because that just takes time, and compilers are slow enough as it is!

A good GC will not really increase the execution time at all -- they turn on only after a significant "headroom" of allocations. For short runs they will hardly do any work.

Also, most of the work will be done in parallel, and I really wouldn't put aside that a generational GC's improved cache effect (moving still used objects close) might even improve performance (all other things being equal, but they are never of course). All in all, do not assume that just because a runtime has a GC it will necessarily be slower, that's a myth.

Re: How safe is Zig?

#100

Post by MaxBarraclough »

afdbcreid wrote: post #24

Do compilers really can never call `free()`? Simple compiler probably can. Most complex probably cannot (I don't want to imagine a Rust compiler without freeing memory: it has 7 layers of lowering (source code->tokens->ast->HIR->THIR->MIR->monomorphized MIR, excluding the final LLVM IR) and also allocates a lot while type-checking or borrow-checking). What is most interesting to me is the average compiler. Does someb…

I imagine plenty of compilers do call free, but here's a 2013 article by Walter Bright on modifying the dmd compiler to never free, and to use a simple pointer-bump allocator (rather than a proper malloc) resulting in a tremendous improvement in performance. [0] (I can't speak to how many layers dmd has, or had at the time.)

The never-free pattern isn't just for compilers of course, it's also been used in missile-guidance code.

[0] https://web.archive.org/web/20190126213344/https://www.drdob...

Post reply on HN