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

251–260 of 427 posts

Re: The Case for Memory Safe Roadmaps

#251

Post by teunispeters »

zozbot234 wrote: post #219
teunispeters wrote: post #172

Earlier quoted context omitted.

Write javascript engines in memory safe languages. I'd vote for rust as rust and javascript's APIs are pretty similar in style, structure, consistency and security/other issues that are not memory safety. On that note, try valgrind on existing javascript engines, you might be "entertained". (I certainly was, but that was some years back.

Most javascript engines are JIT-based and that's hard to make safe, you'd need a complete proof that the emitted assembly is correct. It's similar to the problem of proving correctness for any compiler.

Oh, I've used such tests on other JIT based languages, as well as non-JIT. None made valgrind show quite so much show. I'm not sure I've ever seen less "memory safe" code bases.

Re: The Case for Memory Safe Roadmaps

#252

Post by alkonaut »

lambdaone wrote: post #59

"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.

Having it as default on todays hardware is a non-starter. Few would pay say a 200% perf penalty for arithmetic unless it's on a security critical path. So opt-in it is. And almost all languages already support that type of opt in at the global level or smaller scope.

Re: The Case for Memory Safe Roadmaps

#253

Post by bigbillheck »

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.

What's that got to do with the issue?

Re: The Case for Memory Safe Roadmaps

#254

Post by stouset »

miohtama wrote: post #246
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…

> It's perfectly simple to trash memory in Rust. What makes you think so? Most Rust programmers and programmers from other languages, agree that this is not possible. I might be missing something, but can you give an example of such simple methods to trash memory in Rust, asking from a curiosity standpoint?

I don’t think most Rust programmers agree it’s impossible at all.

There’s always unsafe. I can make a pointer to anywhere by hand and write to it. That would involve some very intentional work, but I could do it if I wanted to.

Re: The Case for Memory Safe Roadmaps

#255

Post by estebank »

miohtama wrote: post #246
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…

> It's perfectly simple to trash memory in Rust. What makes you think so? Most Rust programmers and programmers from other languages, agree that this is not possible. I might be missing something, but can you give an example of such simple methods to trash memory in Rust, asking from a curiosity standpoint?

I would assume they mean through the use of unsafe, which is true, but in practice unsafe code is less common than people that don't write Rust seem to think and tools like Miri help a lot to write unsafe that doesn't write to memory locations you weren't meant to.

Re: The Case for Memory Safe Roadmaps

#256

Post by hollerith »

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…

>Rust doesn't even free you from the need for a runtime

I always thought that Rust was the only memory-safe language that doesn't need a runtime (beyond the libc that every language links to when running on Unix-like OSes). Maybe you could define what you mean by runtime.

Re: The Case for Memory Safe Roadmaps

#257

Post by emporas »

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…

From the article: "In contrast, Rust's explicitness in this area not only made things simpler for us but also more correct. If you want to set a file permission code in Rust, you have to explicitly annotate the code as Unix-only. If you don't, the code won't even compile on Windows. This surfacing of complexity helps us understand what our code is doing before we ever ship our software to users."

https://vercel.com/blog/turborepo-migration-go-rust

Re: The Case for Memory Safe Roadmaps

#258

Post by thinkharderdev »

pier25 wrote: post #198
Filligree wrote: post #79

Earlier quoted context omitted.

Absolutely not. You’re confusing it for Spectre, probably.

The article mentions: > Memory safety vulnerabilities are coding errors affecting software’s memory management code in which memory can be accessed, written, allocated, or deallocated in unintended ways. How can you do any of this without software running in the local machine? Honestly asking.

To take a very simple example (which won't work on modern OS with ASLR):

1. You have a service that takes some user input

2. The service allocates a buffer on the stack for 20 bytes (the max input allowed)

3. Service doesn't actually validate that the user input is 4. It writes the input into the buffer, but keeps writing past the end of the buffer.

5. It eventually overwrites the return pointer so now the user input can control where the execution jumps to on return

6. In the user input, the malicious user includes some shell code to do any arbitrary thing they want.

7. The overwrite the return pointer to jump back into the shell code and now they are executing arbitrary code in the server process.

This sort of thing was embarrassingly easy to do on old linux kernels before ASLR was implemented. Now it is dramatically harder because there are all sorts of countermeasures in place to prevent it (ASLR, stack canaries, executable vs non-executable memory, etc).

To get a sense of what a more modern real world exploit looks like, give https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... a read.

Re: The Case for Memory Safe Roadmaps

#259

Post by matthewdgreen »

estebank wrote: post #248
matthewdgreen wrote: post #227

Earlier quoted context omitted.

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…

> Rust doesn't even free you from the need for a runtime or standard library. Could you elaborate on this? Rust doesn't have a runtime (beyond what C has), and am having trouble understanding what you meant to say about stdlibs.

Rust certainly performs runtime bounds-checking as well as some other tasks, so there is runtime code (even if it's just compiled into executables.) If you want features like async (standard in many language runtimes) you're also going to have to pull in some kind of external runtime dependency. And everyone doing high-level web-style development seems to drag in something like tokio.

Re: The Case for Memory Safe Roadmaps

#260

Post by trealira »

DeathArrow wrote: post #65

Isn't C++ with RAII reasonably safe? I tried to learn/like Rust but it's against how I use to think. If no friendlier safe high speed programming language appears, I rather use C/C++ and trade safety for friendliness.

Modern C++ can still be unsafe. I recently wrote a comment about it here: https://news.ycombinator.com/item?id=38576681
Post reply on HN