Hacker News Reader

Comment by triyambakam | Hacker News Reader

[flagged]

It's a defragmenting stack, garbage collected programming language, and even mentioned as a memory-safe programming language in NSA's "Memory Safe Programming Languages Recommendations".

Why disagree? That's true.

The current implementation is not memory safe. Go uses 128 bit structs for interfaces and slices and assumes that they are updated atomically (when they are not).

It's possible to exploit this to read/write arbitrary memory and to execute arbitrary code. It appears that in practice this is very difficult so the issue is ignored.

https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Data races can cause memory corruption. Make sure to run your test cases with --race

Not the glib root-commenter, but the two big caveats is that Go is memory-safe provided you import neither `unsafe` nor `c`.

That can end up being a pretty restrictive constraint, if it's not something your dependencies cared about. If it is a concern of yours, it's pretty easy to check for at build time.

Well, unsafe says it all. It's "unsafe". On the other hand, I never had to import "C" in any of my projects, yet.

However, if I'm going to wander into CGo realm, I can always pivot to C++, if speed or things implemented in C is that important for me.

No programming language, incl. a particular one which has an orange mascot, is perfect. I also find trying to solve social problems with technology (i.e. let's make programming languages foolproof to enable lazier-er programmers), pointless, to put it mildly.

Honestly, in my eyes Go is a very nice, little language, and I like how it handles.

In my experience, a typical project in orange-mascot language is also more likely to bring in a C dependency through a -sys dep than a typical project in blue-mascot language. (That might be changing with more RIIR, though.)

What language is memory-safe even if you use unsafe and/or arbitrary C linkage?

(I rather suspect triyambakam was referring to undefined behavior on data races.)

Data races can lead to logic bugs that are potentially security sensitive, but memory safety generally refers to getting rid of all control flow hijacking security vulnerabilities which, in many large C/C++ projects, seem to be never-ending. Avoiding data races is more in the category of preventing bugs/crashes while memory safety is about avoiding an entire class of security vulnerabilities.

If I can use a data race to corrupt a jump target, I've done most of the work I need to for any classic memory-safety security vuln.

Go makes this much harder to do than C/C++, especially as it relates to e.g. mishandling user input, but not impossible, even without CGo or unsafe.

I've never seen a single control flow hijack PoC from go data races even in a code golf scenario. I've always wondered if this is possible but I don't think it is. Care to share an example?

Formally verified C code, or WASM[0]

[0] https://news.ycombinator.com/item?id=38613031

WASM is a funny case and I don't agree that it's safe.

When people say WASM is "safe" in this sense what they mean is that it won't corrupt your browser process (or other wasm runtime). That's a useful guarantee! But that's sandboxing, not memory-safety as a language property. You can sandbox C too, that doesn't make C a memory-safe language.

As far as I know you can still trigger unsafe access to the WASM heap, and therefore many kinds of of attacks still work. They don't "break out" but also, lots of valuable data or controllable user behavior is in-heap anyway.

Or, for an even more analogous example, see Google's pNaCl which was a native compilation target that provided many of the same security guarantees as wasm does while avoiding the need for complex JITs. pNaCl utilized a set of rules about control flow transitions and address formation which were enforced by a verifier to allow direct native code execution.

Such a shame this didn’t take off. Couldn’t LLVM in theory be made to target pNaCL instructions?

IIRC, Go has support for atomics, which are handled at the processor directly and effectively eliminates data races.

So, I don't see a problem here.

Having tools to avoid data races don't make it a memory-safe language, unless you strip that phrase of all meaning.

The more interesting question is, would it be worth it to be memory-safe? Rust says yes, and puts a lot of work into statically preventing data races at the cost of (at least) some language ergonomics. Java also says yes, but put a lot of work into making data race impacts well-defined, and on this tends to incur cost (runtime and language development time) with unclear benefits towards actually reasoning about the programs with such races.

Importing `C` declares that you intend to use Cgo instead of Go. Cgo is not Go[1].

[1] https://go-proverbs.github.io

Reply on news.ycombinator.com