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

Why Safety Profiles Failed

circle-lang.org

Post reply on HN
Print view View original

191–200 of 233 posts

Re: Why Safety Profiles Failed

#191

Post by catskul2 »

zahlman wrote: post #47

What actually is this circle-lang site, and who runs it? The main page seems to just redirect to example.com, and I don't recognize the name of the author.

I'm surprised you've not heard of the author (Sean Baxter). He's pretty well known among people who are interested in c++ standards proposals.

He single handedly wrote his own C++ front-end and then proceeded to implement a butt load of extensions which other members of the committees poo-pood as being to hard to implement in the compiler.

Every couple of weeks he implements something new. He's a real joy to follow.

Re: Why Safety Profiles Failed

#192

Post by NobodyNada »

TinkersW wrote: post #122
tsimionescu wrote: post #59

Earlier quoted context omitted.

How would this fix memory safety issues like std::sort(vec1.begin(), vec2.end()) (where vec1 and vec2 are different vectors, of course)? Or strlen(malloc(100))?

It seems to me that it would handle the sort case fine, you would read/write an invalid page and it would fall over(assuming all allocations had invalid pages at the end of the allocation & no 2 allocations share a page). The strlen could be made safe by having the malloc return the address 100 bytes before the end of the page. If it did make it to the end of the 100 bytes it would fall over safely. Result would be n…

> assuming all allocations had invalid pages at the end of the allocation & no 2 allocations share a page

This assumption doesn't hold for real world systems -- most allocations are small, so heap allocators typically support a minimum allocation size of 16 bytes. Requiring each allocation to have its own page would be a 256x memory overhead for these small allocations (assuming 4k pages, and even worse as systems are moving to 16k or 64k page size). Not to mention destroying your TLB.

Also, guard pages only solve the problem if the program tries to access the entire array (like when sorting or reading a string). For other types of out-of-bounds array access where an attacker can control the index accessed, they can just pass in an index high enough to jump over the guard page. You can "fix" this with probing, but at that point just bounds-checking is much simpler and more performant.

Re: Why Safety Profiles Failed

#193

Post by [deleted] »

rurban wrote: post #133

Additionally I still cannot understand why they didn't make iterators safe from the very beginning. In the alias examples some iterators must alias and some not. With safe iterators the checks would be trivial, as just the base pointers need to be compared. This could be done even at compile-time, when all iterators bases are known at compile-time. Their argument then was that iterators are just simple pointers, not…

[deleted]

Re: Why Safety Profiles Failed

#194

Post by zozbot234 »

bluGill wrote: post #131
bjornsing wrote: post #93

Earlier quoted context omitted.

How is it supposed to do that (in the general case)? If I write a C++ program that will index out of bounds iif the Riemann hypothesis is true, then frama-c would have to win the millennium prize to do its job. I bet it can’t.

Often when I look into questions like this I discover the general case is impossible, but simple hysterics can get 99.999% of the cases and so I can get almost all the benefit even though some rare cases are missed.

My own semi-random guess is that "simple hysterics" is indeed how a vast majority (if perhaps not quite 99.999%) of C/C++ devs approaches the code correctness problem - which is why safety mechanisms like the one proposed by OP may in fact be urgently needed. Simple heuristics are likely to be significantly more worthwhile, if appropriately chosen.

Re: Why Safety Profiles Failed

#195

Post by zozbot234 »

bluGill wrote: post #126
lmm wrote: post #118

Earlier quoted context omitted.

> yet the idea that a project no longer actively developed will be rewritten in rust is not? Rewriting it in Rust while continuing to actively develop the project is a lot more plausible than keeping it in C++ and being able to "maintain a stable codebase" but somehow still fix bugs. (Keeping it in C++ and continuing active development is plausible, but means the project will continue to have major vulnerabilities)

I'm not convinced. Rust is nice, but every time I think I should write this new code in Rust I discover it needs to interoperate with some C++ code. How to I work with std::vector in rust - it isn't impossible but it isn't easy (and often requires copying data from C++ types to Rust types and back). How do I call a C++ virtual function from Rust? The above issue is why my code is nearly all C++ - C++ was the best cho…

Rust/C++ interop is in fact complex and not obviously worthwhile - some of the underlying mechanisms (like the whole deal with "pinned" objects in Rust) are very much being worked on. It's easier to just keep the shared interface to plain C.

Re: Why Safety Profiles Failed

#196

Post by zozbot234 »

gpderetta wrote: post #145
o11c wrote: post #91

Earlier quoted context omitted.

With a safe runtime, a pointer is really something like a `struct { u32 allocation_base, allocation_offset;}`. (it may be worth doing fancy variable-bit-width math to allow many small allocations but only a few large ones; it's also likely worth it to have a dedicated "leaf" section of memory that is intended not to contain any pointers) An implementation of `sort` would start with: `assert (begin.allocation_base ==…

one day we will bring segments and far pointers back.

CHERI is pretty much there already

Re: Why Safety Profiles Failed

#197

Post by zozbot234 »

jmull wrote: post #165
wyager wrote: post #4

Earlier quoted context omitted.

> Safe C++ is a really important project What makes you say this? It seems to me like we already have a lower-overhead approach to reach the same goal (a low-level language with substantially improved semantic specificity, memory safety, etc.); namely, we have Rust, which has already improved substantially over the safety properties of C++, and offers a better-designed platform for further safety research.

> It seems to me like we already have a lower-overhead approach ... Rust Rewriting all the existing C++ code in Rust is extremely high-cost. Practically speaking, that means it won't happen in many, many cases. I think we want to find a more efficient way to achieve memory safety in C++. Not to mention, Rust's safety model isn't that great. It does memory safety, which is good, but it's overly restrictive, disallowin…

> It does memory safety, which is good, but it's overly restrictive, disallowing various safe patterns

The "safe" patterns Rust disallows tend to not account for safe modularity - as in, they impose complex, hard-to-verify requirements on outside code if "safety" is to be preserved. This kind of thing is essentially what the "unsafe" feature in Rust is intended to address.

Re: Why Safety Profiles Failed

#198

Post by zozbot234 »

munificent wrote: post #189
rurban wrote: post #133

Additionally I still cannot understand why they didn't make iterators safe from the very beginning. In the alias examples some iterators must alias and some not. With safe iterators the checks would be trivial, as just the base pointers need to be compared. This could be done even at compile-time, when all iterators bases are known at compile-time. Their argument then was that iterators are just simple pointers, not…

The C++ committee and standard library folks are in a hard spot. They have two goals: 1. Make primitives in the language as safe as they can. 2. Be as fast as corresponding completely unsafe C code. These goals are obviously in opposition. Sometimes, if you're lucky, you can improve safety completely at compile time and after the safety is proven, the compiler eliminates everything with no overhead. But often you can…

Rust is unique in being both safe and nearly as fast as idiomatic C/C++. This is a key differentiator between Rust and languages that rely on obligate GC or obligate reference counting for safety, including Golang, Swift, Ocaml etc.

Re: Why Safety Profiles Failed

#199

Post by orf »

bluGill wrote: post #186
Analemma_ wrote: post #163

Earlier quoted context omitted.

> There are reasonably good c++11 conventions for lifetimes [...] Almost nobody follows them [...] I swear I'm not trying to be snarky or rude here, but is it actually a "convention" if almost nobody follows it? This seems like one example of my general issue with C++, in that it could be great if everyone agreed to a restricted subset, but of course nobody can coordinate such agreement and it doesn't exist outside c…

What we have is a human problem. The convention exists in enough places (though in slightly different forms) to call it a convention, but it needs more adoption. Every once in a while someone who writes a lot of Rust will blog about some code they discovered that was 'unsafe' and after looking close they realized it wasn't doing something that fundamentally required unsafe (and often fixing the code to be safe fixed…

What arguments like this fail to understand is that conventions without guardrails, culture and/or guarantees are next to useless.

That’s not a human problem. It’s like saying “this motorway is pitch black, frequently wet and slippery and has no safety barriers between sides, so crashes are frequent and fatal. What we have is a human problem - drivers should follow the convention of driving at 10mph, when it doesn’t rain and make sure they are on the right side of the road at all times”.

Re: Why Safety Profiles Failed

#200

Post by bluGill »

zozbot234 wrote: post #194
bluGill wrote: post #131

Earlier quoted context omitted.

Often when I look into questions like this I discover the general case is impossible, but simple hysterics can get 99.999% of the cases and so I can get almost all the benefit even though some rare cases are missed.

My own semi-random guess is that "simple hysterics" is indeed how a vast majority (if perhaps not quite 99.999%) of C/C++ devs approaches the code correctness problem - which is why safety mechanisms like the one proposed by OP may in fact be urgently needed. Simple heuristics are likely to be significantly more worthwhile, if appropriately chosen.

C++ for sure needs better safety mechanisms. And I don't know the exact number of issues simple heuristics can catch.
Post reply on HN