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

321–330 of 427 posts

Re: The Case for Memory Safe Roadmaps

#321

Post by Zambyte »

dmpk2k wrote: post #238
Zambyte wrote: post #9

Earlier quoted context omitted.

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.

This is true for server systems too. I've often had problems which were ultimately only solvable by rebooting large fleets of servers. Had the servers been running microkernels instead, updating services without full restarts would have been trivial in almost all cases. It's just a better approach overall. I curse the path dependency that led to the current situation.

I consider servers to be human-facing systems. I more meant to account for the fact that L4 is used in Qualcomm modems and Minix is used for Intel ME. I would not consider either of those as human-facing.

Re: The Case for Memory Safe Roadmaps

#322

Post by steveklabnik »

biorach wrote: post #316
mike_hearn wrote: post #300

Earlier quoted context omitted.

For sure C programs have a runtime. I'm debugging an issue right now that is to do with Windows not shipping VCRUNTIME140_1.DLL on out-of-the-box or old versions of Win10, so in that case it's very clear because you can make C programs that won't start due to a missing runtime library. The runtime isn't all that large but every OS has one. On UNIX it's spread over libc, libpthread, libgcc, libm and so on. On Linux st…

That's a rather idiosyncratic definition of "runtime"

(not the parent) You're not wrong but you're not right either. There's basically a colloquialism where many developers say "runtime" to mean "large runtime" and "no runtime" to mean "small runtime," but that doesn't mean that crt0, the "c runtime starting from zero", doesn't exist, just that we've ended up in a place where this gets confusing to talk about because nobody uses the same definitions.

So if it's idiosyncratic really depends on what audience you're talking to.

Re: The Case for Memory Safe Roadmaps

#323

Post by rewmie »

jerf wrote: post #22
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 mil…

[dead]

Re: The Case for Memory Safe Roadmaps

#324

Post by trealira »

conradludgate wrote: post #301
trealira wrote: post #236

Earlier quoted context omitted.

You can also cause a segfault in Go by dereferencing a null pointer. That's another example of not being entirely memory safe.

In this case it's not memory unsafe. It is guaranteed to crash the program (or get caught). It's closer to a NullReferenceException than it is to reading from a null pointer in C. There's no memory exploitation you can pull off from this bug being in a Go program, but you could in a C program

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 memory exploitation you can pull off from this bug being in a Go program, but you could in a C program

Provided the OS sends a SEGV signal for null pointer dereferences, I don't see there being a difference in security between C and Golang in this respect. It's a bigger problem when you're running without an operating system.

Re: The Case for Memory Safe Roadmaps

#325

Post by papichulo2023 »

RhodesianHunter wrote: post #157
anthk wrote: post #111

Earlier quoted context omitted.

>Java Java it's a pest fest for exploits. From those, I'd choose Go, C# (and not totally sure because of AOT/JIT's) and Rust.

>Java it's a pest fest for exploits. Sure, if you haven't used it since the nineties and pay zero attention to new development.

Log4j affair was last year. Kinda funny how HN still bitch about node dependencies and how Java's are more mature.

Re: The Case for Memory Safe Roadmaps

#326

Post by mike_hearn »

teunispeters wrote: post #172
jerpint wrote: post #25

Earlier quoted context omitted.

what do we do about javascript?

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.

How are Rust and JS APIs similar, and why would it matter?

AFAIK the only competitive JS engines written in memory safe languages are GraalJS and other JS-on-the-JVM runtimes. GraalJS has the advantage of being fully up to date, not having any memory unsafe code in it (the JIT compiler that makes it fast is a separate module, also written in a memory safe language, and the JS impl does not have low level code in it). And you can run it on SubstrateVM which is a virtual machine also written in a memory safe language, although of course small parts like the GC need to use unsafe features.

It also has other useful features like sandboxing and the ability to interop with other languages like Python or Java. Plus, it can actually sandbox native code as well because the "languages" that you can run on GraalVM include both wasm and more usefully LLVM bitcode, in which each individual C/C++ allocation becomes GC-managed and bounds checked.

So in terms of memory safety the Graal team are way ahead there.

(disclosure: I recently started part time work with the GraalVM team, but was a long term supporter before that)

Re: The Case for Memory Safe Roadmaps

#327

Post by jvanderbot »

School-Cotton wrote: post #303
jvanderbot wrote: post #274

Earlier quoted context omitted.

This is a common conception, and I agree to a point. However, interfaces matter. At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. At that point, if we have to re-wrap everything in rust to hide the unsafety of the interfaces to the system (sockets, shared mem, etc e…

> At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. It’s quite rare to have to make syscalls directly in Rust, just like it is in c++. Most code in any large enough system is related to the internal logic of the system, not to its interface with the outside world. An…

OK this is reasonable. Perhaps my experience skews towards the lower-level a bit too much. And it's also reasonable I'm misusing the language given it's not my day job.

To answer your question, I'm referring to much of the networking code in socket2 / socket, which uses MaybeUninit when doing non-standard stuff like forming your own packets. (RAW)

Re: The Case for Memory Safe Roadmaps

#328

Post by ok123456 »

munchler wrote: post #93
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 doesn’t even have dynamic memory allocation, so it’s inherently safe.

https://www.ibm.com/docs/en/xffbg/121.141?topic=attributes-a...

No pointer direct arithmetic, though. If you allocate the memory via allocate, you can inquire if it's been deallocated.

Re: The Case for Memory Safe Roadmaps

#329

Post by Zambyte »

ElectricalUnion wrote: post #241
Zambyte wrote: post #82

Earlier quoted context omitted.

Hurd works in the same sense that OpenBSD works. It has very limited hardware support so you'll likely have to run it in a VM, but it does work.

If you're willing to split your workload into VMs in the first place I think application-level segmentation like Qubes starts to become a more interesting idea that microkernels.

There is a lot of flexibility that you get from microkernels outside of isolation that you don't get from virtual machines. I'm not suggesting use one GNU/Hurd VM for one application (similar to what you would get with Qubes). I'm suggesting using one GNU/Hurd VM for many applications.

Re: The Case for Memory Safe Roadmaps

#330

Post by breezedream »

Rebelgecko wrote: post #311
userbinator wrote: post #66

I'm cynically thinking "because they can now target the runtimes instead, and get far more value from their exploits".

NSA is like the governmental version of the "inside you there are two wolves" meme One wolf that wants to help ensure that American computers are secure And one wolf that wants to hoard as many 0-days as possible

I used to work for this agency and your description is the most apt way to characterize the dichotomy between SID (SIGINT) and IAD (information assurance) I can think of.
Post reply on HN