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

361–370 of 427 posts

Re: The Case for Memory Safe Roadmaps

#361

Post by jaisjdkaaaej »

estebank wrote: post #255
miohtama wrote: post #246

Earlier quoted context omitted.

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

Perhaps they aren't writing Rust because those are the people that need to write unsafe code. Chicken and egg. I'm sure it you forced all the C programmers to switch to Rust you would see a lot more use of unsafe.

Re: The Case for Memory Safe Roadmaps

#362

Post by trealira »

dezgeg wrote: post #354
trealira wrote: post #324

Earlier quoted context omitted.

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 huge number of cases the null dereference is not from accessing 0x0 but some offset to it (ie. accessing a struct member or array element that's not the first one). Of course in practice most of the offsets are below the limit where nothing is ever mapped (on Linux vm.mmap_min_addr and seems 64k by default for me) but it's still very possible to have such dereference to not segfault in C. That should not be possib…

Why isn't it possible in Go? If you can use pointers to structures in both Go and C, and you can access the fields of a structure through a pointer in both, then I don't understand why reading a structure field through a null pointer wouldn't cause the dereference of an address like 0x8 in both languages.

Re: The Case for Memory Safe Roadmaps

#363

Post by deely3 »

ryao wrote: post #340

It is a shame that there is no open source equivalent to tools like Astree: https://www.absint.com/astree/index.htm In theory, it is possible to write completely memory safe code in C/C++ using it. As long as its analysis generates no complaints, there are no memory safety issues in the analyzed code.

Can I ask a strawman/obvious question? Does developers of most complex systems use this tool, and if not, then why?

Re: The Case for Memory Safe Roadmaps

#364

Post by ram_rar »

Can someone with a security background enlighten me, on why Python is on the list of "memory safe" languages? Most of the python code I have worked with is a thin wrapper on C. Wouldnt that make python vulnerable as well?

Re: The Case for Memory Safe Roadmaps

#365

Post by timbit42 »

staunton wrote: post #237
timbit42 wrote: post #217

Earlier quoted context omitted.

Employers complain they can't find people with the skills they need yet they refuse to provide training for those skills as it's cheaper to hire someone that was trained in the skills they need by another employer.

> yet they refuse That doesn't seem like a contradiction at all. As you say, they want to hire trained workers rather than providing training themselves. Also, complaining is free while hiring good people is not...

Sure, but my point is that no one is training anyone so now they can't find people with any training, yet they still refuse to train them.

Re: The Case for Memory Safe Roadmaps

#366

Post by synergy20 »

BaculumMeumEst wrote: post #224

In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…

The industry did not abandon C and C++ for Ada in the past, likely it will do the same to Rust. Not to mention C and C++ are both evolving and their toolchains are getting much better nowadays.

After using Rust for a while, I actually decided to stay with to c/c++ for the rest of my career.

Re: The Case for Memory Safe Roadmaps

#367

Post by steveklabnik »

ram_rar wrote: post #364

Can someone with a security background enlighten me, on why Python is on the list of "memory safe" languages? Most of the python code I have worked with is a thin wrapper on C. Wouldnt that make python vulnerable as well?

You are correct that if you call C from Python, you can run into problems. But the fault there lies with the C, not the Python. Pure Python itself is memory safe.

Because memory safety is built on top of memory unsafety, it is generally understood that when discussing things at this sort of level, that we are speaking about the Python-only subset. (Same as any other memory safe language.)

Re: The Case for Memory Safe Roadmaps

#368

Post by dezgeg »

trealira wrote: post #362
dezgeg wrote: post #354

Earlier quoted context omitted.

In huge number of cases the null dereference is not from accessing 0x0 but some offset to it (ie. accessing a struct member or array element that's not the first one). Of course in practice most of the offsets are below the limit where nothing is ever mapped (on Linux vm.mmap_min_addr and seems 64k by default for me) but it's still very possible to have such dereference to not segfault in C. That should not be possib…

Why isn't it possible in Go? If you can use pointers to structures in both Go and C, and you can access the fields of a structure through a pointer in both, then I don't understand why reading a structure field through a null pointer wouldn't cause the dereference of an address like 0x8 in both languages.

Unbounded/large offsets are the critical part. Minimum unit where memory protection can be set is one page (4096 bytes on x86), so compiler could reasonably assume that offsets 0-4095 are always safe to dereference (in the sense that SIGSEGV is guaranteed, which can be then turned into a NullPointerException in the SIGSEGV signal handler) without a NULL check. For anything larger or array accesses, add a explicit check for NULL before dereference.

Re: The Case for Memory Safe Roadmaps

#369

Post by ocschwar »

helsinkiandrew wrote: post #94
DeathArrow wrote: post #55

Earlier quoted context omitted.

>Really, the only memory unsafe languages still in use are C and C++. Ada, Fortran, assembly?

Fortran is probably as bad as C, and Ada isn't truly memory safe - they link to Ada/Spark which is but that doesn't seem to have much widespread use. https://www.adacore.com/about-spark

Fortran is used for scientific computing. The crash of crashing a run on someone's Beowulf cluster is high, but the severity is low.

Re: The Case for Memory Safe Roadmaps

#370

Post by estebank »

jaisjdkaaaej wrote: post #361
estebank wrote: post #255

Earlier quoted context omitted.

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.

Perhaps they aren't writing Rust because those are the people that need to write unsafe code. Chicken and egg. I'm sure it you forced all the C programmers to switch to Rust you would see a lot more use of unsafe.

But there are plenty of projects out there that are written in Rust and have to deal directly with hardware and syscalls. Hubris, a kernel written in Rust has 94 files referencing unsafe[1] out of 414 total .rs files[2]. This is as "bad" a ratio as you're gonna encounter in a project. There are many valid reasons one can have to not use Rust. "I need a lot of unsafe" is not really one.

[1]: https://github.com/search?q=repo%3Aoxidecomputer%2Fhubris+un...

[2]: https://github.com/search?q=repo%3Aoxidecomputer%2Fhubris++l...

Post reply on HN