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

21–30 of 427 posts

Re: The Case for Memory Safe Roadmaps

#21

Post by ethbr1 »

candiddevmike wrote: post #11
wodow wrote: post #6

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

[flagged]

Likely only if you're building government code.

Worked out well enough with Ada in 1978. https://en.m.wikipedia.org/wiki/Ada_(programming_language)#H...

Re: The Case for Memory Safe Roadmaps

#22

Post by jerf »

wodow wrote: post #6

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

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 miles begins with a single step, an elephant is eaten one bite at a time, etc. Rust is just one of the easier and more effective options for a legacy codebase, with the unusual advantage of being able to slip in incrementally. Almost every other language requires a true rewrite.

Re: The Case for Memory Safe Roadmaps

#23

Post by dgacmu »

elromulous wrote: post #17

[flagged]

There's an important difference between an opaque "trust us" recommendation where it's broadly impossible to verify the claim (e.g., Dual_EC_DRBG), and one such as this which is fairly anodyne and merely intended to put more weight behind getting people to move forward in their choice of implementation languages.

The NSA's split offensive/defensive responsibility is bad but that doesn't affect recommendations such as this.

Re: The Case for Memory Safe Roadmaps

#26

Post by ianlevesque »

Zambyte wrote: post #9
dharmab wrote: post #4

Earlier quoted context omitted.

Based on early days of Rust in the Linux kernel, the segmentation of safe and unsafe code can significantly reduce the surface area within a kernel.

I realize this is beating a dead horse, but it really is a shame that microkernels didn't win for human-facing Unix systems. This issue was recognized and basically solved decades ago, and we're still almost there.

Yeah, I've wondered a bit if the Spectre class of vulnerabilities was discovered a couple decades sooner if it would have changed the course of history there.

Re: The Case for Memory Safe Roadmaps

#29

Post by nobleach »

Zambyte wrote: post #9
dharmab wrote: post #4

Earlier quoted context omitted.

Based on early days of Rust in the Linux kernel, the segmentation of safe and unsafe code can significantly reduce the surface area within a kernel.

I realize this is beating a dead horse, but it really is a shame that microkernels didn't win for human-facing Unix systems. This issue was recognized and basically solved decades ago, and we're still almost there.

Hurd any day now, right?

I do wonder what this landscape could have looked like if all of the effort had gone behind a Mach-based microkernel. I read all of the back and forth between Tanenbaum and Torvalds. At the time, I was just so excited to see "free and open" winning.

I should specify that the XNU Kernel from Darwin/OSX took a lot of my attention when it first premiered.

Post reply on HN