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

Memory Safety

memorysafety.org

Post reply on HN
Print view View original

111–120 of 157 posts

Re: Memory Safety

#111

Post by fweimer »

checker659 wrote: post #97

I never understood why software has to pay for the lack of memory safety primitives in the hardware.

People have tried, and so far, achieving safety through trusted compilers and (fairly complicated) run-time support has been much more efficient. A small team could probably design a RISC-V CPU with extensions for hardware-assisted bounds checking and garbage collection, but any real CPU that they can built would likely have performance levels that are typical for research-oriented RISC-V CPUs. Doing the same thing in software on a contemporary commercially established CPU is going to be much, much faster.

Re: Memory Safety

#112

Post by [deleted] »

pizlonator wrote: post #8

> Languages that are not memory safe include C, C++, and assembly. False. C and C++ are not memory safe if you use the most common and most performant implementations, sure. At some point these folks are going to have to accept that caveat

[deleted]

Re: Memory Safety

#113

Post by pjmlp »

saagarjha wrote: post #110
pjmlp wrote: post #106

Earlier quoted context omitted.

They are, pity that Rust type system has nothing to prevent them outside a very specific use case of in-memory data structures and threads. Make those in-memory data structures writable via OS IPC and all bets are open, regarding what other processes, or kernel extensions, do to the memory segment. Fearless concurrency is welcomed, but lets not overlook the fine print in systems programming.

If you have both sides cooperating, then it's perfectly reasonable to write a safe interface on top of shared memory. If not…well, what do you suggest? Also, pointing at the overwhelming majority of code and going "this is a very specific use case" is also kind of wild, because even in IPC scenarios there will be in-memory data that needs protection.

What I suggest is getting the marketing message correctly.

Re: Memory Safety

#114

Post by pjmlp »

fweimer wrote: post #108
pjmlp wrote: post #104

Earlier quoted context omitted.

Bounds checking of pointers, C Machine kind of. Solaris and Linux SPARC since 2015, for example. https://docs.oracle.com/en/operating-systems/solaris/oracle-... https://docs.kernel.org/arch/sparc/adi.html ARM MTE, as another one, https://learn.arm.com/learning-paths/mobile-graphics-and-gam...

These approaches can only detect linear overflows deterministically. Use-after-frees (temporal safety violations) are only detected with some probability. It's mostly a debugging tool. And MTE requires special firmware, which is usually not available in the cloud because the tag memory reservation is a boot-time decision.

Still better than status quo on most systems.

It is kind of interesting how all attempts to improve security are akin to arguing about usefulness of seatbelts when people still die wearing them.

Re: Memory Safety

#115

Post by bheadmaster »

fweimer wrote: post #109

I find it strange that this web site completely ignores the Java ecosystem, which offers memory-safe implementations for most of the protocols and services listed.

Can I use the Java implementations in another language without significant headache?

Re: Memory Safety

#116

Post by SkiFire13 »

pjmlp wrote: post #106
saagarjha wrote: post #66

Earlier quoted context omitted.

Why do you think data races are not a practical source of bugs?

They are, pity that Rust type system has nothing to prevent them outside a very specific use case of in-memory data structures and threads. Make those in-memory data structures writable via OS IPC and all bets are open, regarding what other processes, or kernel extensions, do to the memory segment. Fearless concurrency is welcomed, but lets not overlook the fine print in systems programming.

Are you perhaps confusing data races with race conditions?

Re: Memory Safety

#117

Post by pjmlp »

SkiFire13 wrote: post #116
pjmlp wrote: post #106

Earlier quoted context omitted.

They are, pity that Rust type system has nothing to prevent them outside a very specific use case of in-memory data structures and threads. Make those in-memory data structures writable via OS IPC and all bets are open, regarding what other processes, or kernel extensions, do to the memory segment. Fearless concurrency is welcomed, but lets not overlook the fine print in systems programming.

Are you perhaps confusing data races with race conditions?

Nope, because it depends on how memory storage is mapped on the process, linker scripts and other fun tricks in systems programming, outside Rust's type system.

Re: Memory Safety

#118

Post by SkiFire13 »

i_am_a_peasant wrote: post #29
websiteapi wrote: post #12

Earlier quoted context omitted.

is there actually a programming language that makes race conditions impossible (I am not being facetious, I actually do not know)? if the existence of races makes a language unsafe, then aren't all languages unsafe?

isn’t that the point of languages that have first class actor models something something?

Even in those languages you can easily have the equivalent of race conditions simply due to the order messages are received.

Re: Memory Safety

#119

Post by rurban »

codys wrote: post #2

This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.

And they are also promoting rust as memory safe, whilst ignoring the true memory safe languages (the ones with a GC), which is kinda hilarious.

Politicians

Post reply on HN