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

Memory safety absolutists

itsallaboutthebit.com

Post reply on HN
Print view View original

221–230 of 272 posts

Re: Memory safety absolutists

#221

Post by sirwhinesalot »

pjmlp wrote: post #220
sirwhinesalot wrote: post #216

Earlier quoted context omitted.

For std::string and std::vector yes, but not for std::span (until C++26) for reasons I cannot understand.

That is standardese, you get them all bounds checked by using specific compiler flags. Here is for VC++ https://github.com/microsoft/STL/blob/2a62bf7b4079f0a3e33ec8... You just have to define the proper iterator level for enabling bounds checking. Other compilers have similar approaches. I chose VC++ on purpose, because it is what I know better, and is famously trailing behind C++26 features. Then there are the Tclas…

I wasn't aware of that VC++ feature, TIL, thanks!

Re: Memory safety absolutists

#222

Post by inigyou »

uecker wrote: post #178
inigyou wrote: post #175

Earlier quoted context omitted.

But memory safety is one of the big ones.

Most people I know that had security incidents did not have this because of memory safety issues. But it does not matter, even without memory safety issues out of the picture, you would need to update your software and be wary of supply chain attacks. (Actually, I can't remember a single incident where somebody I knew was directly affected by a memory safety issue)

Memory corruption is among the hardest things to exploit but also the most powerful. It used to be easier before things like ASLR and NX-stack.

Re: Memory safety absolutists

#224

Post by tialaramex »

smj-edison wrote: post #208
tialaramex wrote: post #172

Earlier quoted context omitted.

Given you like pointers so much a dislike for Rust would make sense if Rust didn't have pointers, but it does and IMO as somebody who spent years getting paid to write in C, Rust's pointers are better. I don't know if Zig has made any clear decisions about this (chime in any Zig experts) but in C [and C++] the pointers are crap because they're "zapped" when the thing pointed to is gone. Now of course in reality your…

Not familiar with the idea of "zapped", and I thought that Rust had a similar provenance model? Working with pointers in Zig is much nicer, since 1. They're not nullable. If you want a nullable pointer, you would use `?*Object` instead of `*Object`. 2. They distinguish between single item and multi-item pointers. `*u8` is a pointer to a single u8, so I couldn't add to it or index it. `[*]u8` is a multi-item u8, which…

Today the C and C++ standards do not have a provenance model. The model Rust chose is certainly related to the PNVI-ae-udi model proposed for C, in particular "Provenance Not Via Integers" is a core choice in both schemes. Martin Uecker (who has commented elsewhere in this thread) would I think say they're more similar than I would and he is an expert in this area as he co-authored the C proposal.

Zap isn't much related to provenance, it's more of a difference in philosophy about what pointers are for. With zap they're a very bare bones reference type, they always refer to things which exist and that's all, it's important that they never point anywhere without in fact referencing a thing. Without zap most of the behaviour you associate with hardware addresses works, you can do arithmetic on them, including atomic compare operations, you can use them as parameters to MMIO features and so on. Since C doesn't have any other reference types their role in C makes sense, in Rust and C++ of course actual reference types also exist.

Re: Memory safety absolutists

#225

Post by pseudony »

kmeisthax wrote: post #7

I was not aware of the antagonism from the Zig / Fil-C people to Rust, but it makes absolutely no sense. Like, of course you can prevent all memory safety errors by using a garbage collector. That has been known since the 90s. In fact, there was a good two decades after Java released where all the research on memory safety just stopped, because the standard answer became "use a GC". If you couldn't use GC, you were s…

It is not universal. But imagine you enjoying a programming language (zig, odin, c, c++, …) and half the time some post/article about it comes up, 15% or so of the comments are “kindly” missionaries who just want to let you know how backwards you are, but that there is hope for you yet - as if anyone has been living under a rock solid enough to not hear about Rust.

Honestly, it gets tiresome and adds nothing useful to all these posts. And since those drive-by missionaries aren’t spreading the good word of ocaml/java/go/haskell but Rust - well, then eventually you tire of the Rust community. It has a missionary/redemption problem.

Re: Memory safety absolutists

#226

Post by DaveParkCity »

I'm in the (near) memory safety absolutionist camp.

Fil-C is an amazing technology, and we should use it, but we should also recognize its limitations.

An as-written JIT or GC can not be compiled with Fil-C because they are inherently memory unsafe.. which means one of the biggest user CVE targets by volune, Google Chrome, not only can not be compiled by Fil-C -- it also can't consume Fil-C compiled libraries. (Chrome not only has v8 jit, but 2 different GC systems - V8's and Oilpan, plus PartitionAlloc)

Which means Fil-C is an amazing tech for securing the manual-deallocator daemons and backends, but does not secure the biggest attack vector on 2 billion consumer devices.

This is why i'm writing a maximally memory safe browser in dotnet where the only unsafe will be the FFI and RyuJIT underneath me. [1]

I also think we have gone too long with poor operating system safety tools. I want a system based on Andrew Valencia's VSTa's hierarchial capability system. In that system protection ids are hierarchial and infinitelly narrowable without any special authority. So user.david can forge user.david.browser which can forge user.david.browser.site.ycombinator and so on. The closest we have to this today is (relatively) heavy weight virutlized containers.

[1] https://unsoliciteddave.blogspot.com/

Re: Memory safety absolutists

#228

Post by [deleted] »

benj111 wrote: post #162
smj-edison wrote: post #21

This is perhaps a different take, but one reason I love Zig and C is because I've learned how to reason in pointers. I've worked with Rust in the past on a ~12,000 LOC side project, so I was all in with tree ownership and XOR mutability. But it turns out there's all sorts of delightful data structures that you can only express with unsafe in Rust. Intrusive doubly linked lists are the coolest thing ever. The fact tha…

See now this is why I don't quite get everyone jumping on the rust bandwagon. This is a limitation of the rust model. You could have a language where intrusive linked lists are provably safe. That's not to say rust doesn't work, but it's the first language I'm aware of that's attempted compile time memory safety, and no body seems to be talking about how to do it better.

[deleted]

Re: Memory safety absolutists

#229

Post by himata4113 »

Brian_K_White wrote: post #89
himata4113 wrote: post #70

Earlier quoted context omitted.

It had one bad cve it seems, but that's exactly what I mean. It only takes one mistake, of course you can learn and never make those mistakes again, however, that is an unrealistic expectation in software that receives hundreds of feature updates a year especially when it comes to core applications as basic as communication when it wants to support image previews, reels and whatnot.

There will always be one, so "it only takes one" is meaningless and invalid. That leaves less is better than more, and any form of less is as good as any other form of less.

This is pretty hard to argue since for example: WireGuard is a finished piece of software. It gets: no feature updates, was designed in-full before a single line of code was written and has stood the test of time. You cannot compare that to some desktop application that has a thousand features with 100's more added every year.

Re: Memory safety absolutists

#230

Post by Animats »

inigyou wrote: post #203
Animats wrote: post #56

Earlier quoted context omitted.

The important thing from a performance standpoint is to be able to hoist bounds checks out of inner loops. This avoids a check on each iteration. Languages which have constructs such as for foo in bartab {} can usually hoist checks out of inner loops almost for free. I used to argue with the C++ committee about to when it's OK to catch an error early. If you write #define LEN 1000 int tab[LEN]; for (auto p = tab; p++…

#define LEN 1000 int tab[LEN]; for (auto p = tab; p++; p Not shown in frame: foo() calls exit(0) and tab always contains a 42. The current standard allows the compiler to hoist unsafety only if there's no possibility of I/O or volatile memory access. This is the reason for the rule that infinite loops without the above are undefined behavior - it allows the compiler to merge two loops, the second of which might crash…

Right, tab+LEN. The intended error was "<=" instead of "<".
Post reply on HN