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

The Case for Memory Safe Roadmaps

nsa.gov

Post reply on HN
Print view View original

341–350 of 427 posts

Re: The Case for Memory Safe Roadmaps

#341

Post by remexre »

trealira wrote: post #324
conradludgate wrote: post #301

Earlier quoted context omitted.

In this case it's not memory unsafe. It is guaranteed to crash the program (or get caught). It's closer to a NullReferenceException than it is to reading from a null pointer in C. There's no memory exploitation you can pull off from this bug being in a Go program, but you could in a C program

It's only guaranteed because of the operating system's sandboxing. > It's closer to a NullReferenceException than it is to reading from a null pointer in C. No, it's exactly the same as a null pointer dereference in C, because it is literally reading from a null pointer in Go as well. In Java, the compiler inserts null checks before every single dereference and throws an exception for null references. > There's no me…

> In Java, the compiler inserts null checks before every single dereference and throws an exception for null references.

Doesn't OpenJDK install a SIGSEGV handler, and generate the exception from that on a null dereference?

(AFAIK, a lot of runtimes for GC'd languages that support thread-based parallelism do so anyway, because they can use mprotect to do a write barrier in hardware.)

Re: The Case for Memory Safe Roadmaps

#342

Post by steveklabnik »

ryao wrote: post #335
kmeisthax wrote: post #216

Earlier quoted context omitted.

Rust is already most of the way there. The default math operators still do implicit underflow and overflow, but the behavior is actually well defined: debug builds panic on overflow and release builds wrap on overflow. There is no way to get a C-style "demons fly out my nose" overflow. There's also explicit arithmetic functions that let you choose your overflow behavior: * Checked: return None on overflow * Wrapping:…

Do you mean the C compiler's optimization passes can do strange things to code paths that overflow? The last I checked, C would wrap on overflow too. Rust uses the same compiler backend as C, so it could very well have the same behavior emerge from compiler optimization passes.

> it could very well have the same behavior emerge from compiler optimization passes.

It can not, because "compiler optimization passes" is not the root cause of this behavior: it is that it is undefined behavior in the language itself. This is what gives the compiler license to make those transformations. In Rust, it is not undefined behavior, and therefore the compiler does not have the right to make those transformations for Rust code.

Just because Rust uses LLVM does not mean that suddenly it inherits C's semantics. This has actually happened (well, more specifically, C++'s semantics, C was accidentally inheriting them as well IIRC) at least one time before, but that is a bug in LLVM that was fixed. Now each language has the proper semantics here, and it all works just fine. (I am referring to the behavior with regards to infinite loops with no side effects.)

Re: The Case for Memory Safe Roadmaps

#343

Post by steveklabnik »

Xylakant wrote: post #333
steveklabnik wrote: post #315

Earlier quoted context omitted.

Ferrocene has said in the past they plan on going for DO-178 in the future.

But we do not plan on rewriting SQLite, that much I can say :) (My reading is that the GP points to the exemplary achievement that SQLite has reached a close to (security) bugfree, at what I consider a nearly superhuman effort)

That's a good point, I certainly didn't mean to imply that you were!

Re: The Case for Memory Safe Roadmaps

#344

Post by [deleted] »

slimsag wrote: post #150
jonnytran wrote: post #96

Earlier quoted context omitted.

It's unfortunate that there's no mention that not all these languages are equally safe. Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Adding some more for other languages: * many GC'd languages like Go, C#, Java make it harder to leak memory, while languages where reference counting is more prevalent (Python, Rust) it can be easier to leak memory due to circular references. * Languages with VMs like C#/Java/Python may be easier to sandbox or execute securely, but since native code is often called into it breaks the sandboxing nature. * Formally-ver…

[deleted]

Re: The Case for Memory Safe Roadmaps

#345

Post by corethree »

photonbeam wrote: post #275
corethree wrote: post #186

Earlier quoted context omitted.

Rust is a little too safe imo. I want a rust with just shared pointers and no move semantics. I guess go would be it? But go is too opinionated with a bunch of stupid go specific philosophies like the weird error handling and the stupid packaging rules. Go is also opinionated with concurrency. So that's an issue too.

Ocaml then?

I like functional, but this isn't what I'm referring too. OCaml by being functional is opinionated.

Re: The Case for Memory Safe Roadmaps

#346

Post by UncleMeat »

2devnull wrote: post #308
UncleMeat wrote: post #222

Earlier quoted context omitted.

"${LANGUAGE} programmers" aren't really a thing. Our important skills translate fairly cleanly between ecosystems.

Ok fine, then to quote the parent to whom I was responding, “Rust advocates.” I am willing to bet that most of those “Rust advocates” are programmers who code in Rust but I’m fine with not calling them that. I agree that good programmers should be able to work in different languages, operating systems, countries.

My point is that even in a world where the government mandates that certain applications that would otherwise be written in C++ are instead written in Rust or Swift we wouldn't see some massive loss of work for people who currently program in C++.

Re: The Case for Memory Safe Roadmaps

#347

Post by ralphc »

jmclnx wrote: post #32

I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.

It doesn't take long to find comments on HN about how there are plenty of people out there that can do a good interview but can't code their way out of a paper bag. The standard solution to this, and I've been on the receiving end of this, is to have someone as a contractor for 3+ months before converting them to full time employee.

I'm afraid your approach would mean hiring someone and spending time and money on them before you're sure they'll work out in your organization. Few want to train contractors and firing FTEs after 3 months and change is a dim prospect as well.

Re: The Case for Memory Safe Roadmaps

#348

Post by stjohnswarts »

adrianN wrote: post #46
hospitalJail wrote: post #2

At least my usecase has C completely disconnected from the internet. I have no idea how this is going to work at the OS level.

A lot of industrial automation was built with an offline usecase in mind. Then someone invented the IIoT.

The Internet Internet of Things?

Re: The Case for Memory Safe Roadmaps

#350

Post by stouset »

matthewdgreen wrote: post #227
jvanderbot wrote: post #151

Earlier quoted context omitted.

Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Ru…

What I don't understand is the excitement for using Rust vs. using garbage collected languages like Golang, at least for high-level applications (performant or low-level systems applications are excepted here.) My experience is that an experienced programmer can be a lot more productive quickly with Golang, since they don't need to climb the Rust borrow-checking learning curve. Rust doesn't even free you from the nee…

I’m writing a sibling comment to answer the parent’s question directly rather than the meta-argument from my original reply.

> What I don't understand is the excitement for using Rust vs. using garbage collected languages like Golang… since they don't need to climb the Rust borrow-checking learning curve.

Because, in my experience, climbing that learning curve has made me a better programmer more than nearly any other change in my long career. And that benefit has extended to code in every language I write.

The borrow checker isn’t just some hurdle to get in your way; it’s trying to tell you (awkwardly at times and perhaps less helpfully than one would wish) something fundamental about the way you think about and design programs. Internalizing that lesson can bring significant benefits on designing systems with clean boundaries that are easier to test, easier to reason about, and easier to compose.

Besides that, Rust greatly assists you (through features other than the borrow checker) in building software that is correct. This means it will tell you in a much wider variety of scenarios when future code invalidates previous assumptions. This is invaluable for projects that we expect to survive for a long time since the time a project is maintained will dwarf the time it’s under active development. And it will almost certainly be maintained by someone without the full context of the original developer(s). This is true even if the maintainer is the same person who wrote it in the first place, since our mental model of a program bitrots far faster than the program itself.

In practice, this aligns with my personal experience. Go projects end up with a lot of implicit assumptions that are silently violated by future work and expose bugs. They crash on nil pointer derefs. They accrue a multitude of linting tools that usually paper over some of the language’s shortcomings, but only in common cases. And they become painful to maintain as the original developers move on to other projects, with new changes grafted haphazardly into dozens of touch points instead of cleanly in one or two places. Yes, you can “easily” follow what any particular function does, but to do so you have to parse out and mentally model every minute detail, rather than being able to reason at a high level.

Post reply on HN