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

201–210 of 427 posts

Re: The Case for Memory Safe Roadmaps

#201

Post by manishsharan »

natsucks wrote: post #163
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.

"In attempts to mitigate the dangers of memory unsafe code in C and C++, many software manufacturers invest in training programs for their developers. Many of these training programs include tactics designed to reduce the prevalence of memory unsafe vulnerabilities produced by those languages. Additionally, there are numerous commercial and industry trade association training programs. Further, various organizations…

Does the training go beyond showing them how to use Valgrind ?

Re: The Case for Memory Safe Roadmaps

#202

Post by bumby »

wolvesechoes wrote: post #142
helsinkiandrew wrote: post #86

Earlier quoted context omitted.

And many buildings were built deliberately poorly to make a quick buck - or caught fire too easily or fell down in minor earthquakes (or worse damage other property/people). Peoples homes are a major financial commitment and can ruin people if they're not up to scratch. The regulations are to ensure the 10% of bad builders/developers don't ruin peoples lives.

And yet, poorly build buildings are still being build, but at least now it is much harder and much more expensive for a person to build their own house, and for a small construction companies to compete with giant monopolies. Yay!

"Poorly build [sic] buildings" depends on context. Even low-quality builds in the US are relatively safe. It's disingenuous to imply they are of the same quality as in countries where building codes are effectively non-existent.

Re: The Case for Memory Safe Roadmaps

#203

Post by corethree »

jonnytran wrote: post #96
wodow wrote: post #6

Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift

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...

That's fine. Safety with concurrency doesn't exist in any language. Only rust is special in that it tries to provide safety with concurrency as well. I haven't seen any other language besides rust actually do this.

The reason is obvious. There's a high cost to this type of safety. Rust is hard to use and learn and many times it's safety forces users to awkwardly organize code.

And there's still the potential for race conditions even though the memory is safe, you don't have full safety.

Re: The Case for Memory Safe Roadmaps

#204

Post by matthewaveryusa »

gosub100 wrote: post #105

Can someone explain why we can't double-down on C++ and, through compiler wizardry and reduction in toolset (say, strings can only be fixed-size at 32 chars, 64, or 256 long. No raw pointers, allocator zeroes out all freed memory), achieve a memory-safe language? Obviously, making certain concessions would be a deal-breaker for some, but it might be viable for legacy codebases. If you were to try to make C++ memory-s…

I think you would need to go the go/rust route of explicitly calling out unsafe code blocks.

Re: The Case for Memory Safe Roadmaps

#205

Post by alex_smart »

marcosdumay wrote: post #119
champagnepapi wrote: post #31

But how are we going to trade stocks in nano seconds without C++?!

High speed fiance is mostly done in Java and Haskell, because mistakes are expensive. (And yeah, it's one of the very few fields that Haskell enters the list.)

HFTs have pretty much all moved to FPGAs for sub-microsecond latencies in past few years. C++ can’t compete with that, let alone Java or Haskell.

Re: The Case for Memory Safe Roadmaps

#206

Post by kevincox »

jvanderbot wrote: post #151
jerf wrote: post #22

Earlier quoted context omitted.

Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. "Rewrite it in Rust" gets a bit of pushback, perhaps even justified, but at this point in time I'll take anything that just reduces that behemoth in size. The journey of a thousand mil…

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…

I don't think C and C++ are that different. I agree that C++ gives you tools to make safer abstractions, but it still gives little tools to enforce these abstractions. For example std::shared_ptr being easy to use is a great improvement as in many cases you can just use it rather than trying to prove that you don't need it so that you don't need to bother implementing your own reference counting.

In C++ vec[999] is a buffer overflow and you can index any pointer even if it isn't supposed to be an array. There are so many easy mistakes that can be made and aren't obvious to a reviewer. Maybe with a very strong linter you can consider C++ very distinct from C, but by default I don't think it is that different.

> I can write a buffer overflow in any language

Try doing it in JavaScript? If so the Mozilla security team would appreciate a private disclosure. Of course it is possible in any non-sandboxed Turing complete language, but there is a huge difference between the default accessor of the most used container type allowing it vs needing to use functions in the `sun.misc.Unsafe` package or wrapping your code in an `unsafe` block. Making code that may cause a buffer overflow explicit is a night and day difference. It means that you can't do it via a typo in the vast majority of your code, and it will grab the attention of your reviewer very quickly. Isolating the part of the code that can cause buffer overflows to a small part greatly raises the attention that is given to those areas, and greatly reduces the chance of them occurring.

I don't think that Java or Rust prevent all buffer overflows, but I also don't think that it is possible to write C or C++ without them. Sure, it is possible to be careful and avoid most of the buffer overflows most of the time, but we and our reviewers are just human so we will never prevent all of the buffer overflows all of the time.

I don't think that this recommendation is under the impression that "memory safe languages" will prevent all buffer overflows, but the idea is that they will greatly reduce the number. In many situations, I would guess the majority of them, this is a good tradeoff.

Re: The Case for Memory Safe Roadmaps

#207

Post by synergy20 »

disgruntledphd2 wrote: post #191
synergy20 wrote: post #68

Earlier quoted context omitted.

absolutely correct, in fact now some new hires are expected to do a few git-commit the first day(looking at you, Meta). no wonder so many bugs here and there.

> absolutely correct, in fact now some new hires are expected to do a few git-commit the first day(looking at you, Meta). Meta have a phenomenally good training program, called Bootcamp for basically everyone in engineering, so they're probably not the example you're looking for.

I recall meta expects new hires to do first commit the first day, not sure how its training will help in this scenario, this is in no way saying meta has no good training, it just does not add up here though.

Re: The Case for Memory Safe Roadmaps

#208

Post by datameta »

osigurdson wrote: post #156
brookst wrote: post #144

Earlier quoted context omitted.

Not to worry! In the future most programmers will undergo tens of thousands of GPU hours of training.

We will see. I suspect things will not turn out as expected.

There might be a layer of humor you didn't pick up on.

Re: The Case for Memory Safe Roadmaps

#209

Post by [deleted] »

synergy20 wrote: post #60
chewmieser wrote: post #18

Earlier quoted context omitted.

Oh boy... Nothing is mandated here. These are just suggestions from experts. Don't take them if you don't want to.

wait for gov contract projects mandate them in the fine prints, it's a signal that is serious enough for anyone interested in doing any software-related business with gov, for them, this is nearly the same as 'mandated'

[deleted]
Post reply on HN