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

61–70 of 157 posts

Re: Memory Safety

#61

Post by II2II »

roblabla wrote: post #13
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

C and C++ as defined by their current standards are memory unsafe. You may argue that some specific implementations manage to stay as memory safe as they can get away with, but even then, features like union prevents a fully memory-safe implementation.

Question: why is a union memory unsafe?

My meager understanding of unions is that they allow data of different types to be overlayed in the same area of memory, with the typical use case being for data structures that may contain different types of data (and the union typically being embedded in a struct that identifies the data type). This certainly presents problems with the interpretation of data stored in the union, but it also strikes me that the union object would have a clearly defined sized and the compiler would be able to flag any memory accesses outside of the bounds of the union. While this is clearly problematic, especially if at least one of the elements is a pointer, it also seems like the sort of problem that a compiler can catch (which is the benefit of Rust on this front).

Please correct me if I'm wrong. This sort of software development is a hobby for me (anything that I do for work is done in languages like Python).

Re: Memory Safety

#62

Post by woodruffw »

II2II wrote: post #61
roblabla wrote: post #13

Earlier quoted context omitted.

C and C++ as defined by their current standards are memory unsafe. You may argue that some specific implementations manage to stay as memory safe as they can get away with, but even then, features like union prevents a fully memory-safe implementation.

Question: why is a union memory unsafe? My meager understanding of unions is that they allow data of different types to be overlayed in the same area of memory, with the typical use case being for data structures that may contain different types of data (and the union typically being embedded in a struct that identifies the data type). This certainly presents problems with the interpretation of data stored in the uni…

A trivial example of this would be a tagged union that represents variants with control structures of different sizes; if the attacker can induce a confusion between the tag and the union member at runtime, they can (typically) perform a controlled read of memory outside of the intended range.

Rust avoids this by having sum types, as well as preventing the user from constructing a tag that’s inconsistent with the union member. So it’s not that a union is inherent unsafe, but that the language’s design needs to control the construction and invariants of a union.

Re: Memory Safety

#63

Post by aw1621107 »

adapower wrote: post #50
sealeck wrote: post #19

Earlier quoted context omitted.

This is a bit like saying everyone would be a bit less jaded if the plane staying in the air wasn't hung over the Boeing 737 MAX 8 designer's heads by certain communities and used as an existential threat to the company.

A better analogy might be how Ada was hung over the heads of those using C and C++, to the point of Ada being mandated by law in certain niches. And then Ada software caused the loss of US$370 million with Ariane 5.

> to the point of Ada being mandated by law in certain niches.

> And then Ada software caused the loss of US$370 million with Ariane 5.

This seems like a bit of a non-sequitur? Ariane is an EU rocket and the flight you're referring to was carrying an EU payload, and I don't think it was ever subject to the US DoD Ada mandate or an EU equivalent (which I'm not sure ever existed?).

(Also a bit of a nitpick, but I don't think the US DoD Ada Mandate was a law per se; it was a DoD policy and not something the US Congress passed).

It's probably somewhat disputable as to whether the Ariane failure was "due to Ada" or whether other higher-level concerns were responsible (e.g., reusing the Ariane 4 software without revalidation)

Re: Memory Safety

#64

Post by II2II »

coffeeaddict1 wrote: post #49
II2II wrote: post #46

Earlier quoted context omitted.

Commenting from the sidelines: Doesn't modern C++ offer the ability to write memory safe code? The primary distinguishing difference from Rust, on this front, is that Rust is memory safe by default (and allows them to override memory safety with code that is explicitly declared as unsafe) while C++ requires the developer to make a conscious effort to avoid unsafe code (without providing facilities to declare code as…

> C++ requires the developer to make a conscious effort to avoid unsafe code The problem is much worse than how you put it. I've written C++ for more than a decade and it's painful to constantly having to worry about memory safety due to enormous complexity of the language. Even if you are super diligent, you will make a mistake and it will bite you when you expect it the least. Relying on clang-tidy, non-default com…

Admittedly, I am more of a hobbiest when it comes to C++ development. I try to keep track of things, but I started learning the language before it was standardized and I switched to other languages shortly after it was standardized (never mind the introduction of memory safe option in the standard libraries, which occurred in the 2000's). That said, memory safety has been a consideration, and a feature, for nearly 20 years now. It seems to me that people should have been taught how to approach it for nearly 20 years now. Sure, you can break the rules. Sure, anyone working with older code would have been exposed to bad code. Yet it shouldn't be a universal problem unless people are deliberately seeking out shortcuts (since writing memory safe code in C++ is messier than writing unsafe code).

Re: Memory Safety

#65

Post by pizlonator »

II2II wrote: post #61
roblabla wrote: post #13

Earlier quoted context omitted.

C and C++ as defined by their current standards are memory unsafe. You may argue that some specific implementations manage to stay as memory safe as they can get away with, but even then, features like union prevents a fully memory-safe implementation.

Question: why is a union memory unsafe? My meager understanding of unions is that they allow data of different types to be overlayed in the same area of memory, with the typical use case being for data structures that may contain different types of data (and the union typically being embedded in a struct that identifies the data type). This certainly presents problems with the interpretation of data stored in the uni…

Canonical example:

    union {
        char* p;
        long i;
    };
Then say that the attacker can write arbitrary integers into `i` and then trigger dereferences on `p`.

Re: Memory Safety

#66

Post by saagarjha »

crawshaw wrote: post #6
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.

I am not sure if you are: 1. attempting to retcon garbage collected languages as not memory safe, or 2. discussing a particular implementation choice of the standard Go runtime that was made because it is not a practical source of bugs (see https://research.swtch.com/gorace , it is not an inherent feature of the language, just the implementation, and it is the right practical choice) But either way: this is the sort…

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

Re: Memory Safety

#67

Post by saagarjha »

redbeeswimming wrote: post #38
vlovich123 wrote: post #33

Earlier quoted context omitted.

Firstly, the existence of unsafe does not inherently mean the code isn’t memory safe. Secondly, memory safety does not mean no security vulnerabilities. What it does mean is that 80% of the most commonly found vulnerabilities (as gathered through statistical analysis of field failures) are gone. It means that the price for finding a vulnerability is higher. And also sudo-rs precisely removes a lot of complexity that’…

> Firstly, the existence of unsafe does not inherently mean the code isn’t memory safe. That does not contradict what I wrote. I am confounded by your post, since an article with vulnerabilities in sudo-rs was posted. You can also read https://news.ycombinator.com/item?id=46388181 > TLDR: this is a lazy knee jerk critique. Please do better in the future. TL;DR: This is a lazy knee jerk critique. Please do better in t…

Memory safety does not make your code free of vulnerabilities.

Re: Memory Safety

#68

Post by aw1621107 »

redbeeswimming wrote: post #41
Dylan16807 wrote: post #39

Earlier quoted context omitted.

If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand. "Modules with unsafe" should be a lot lot less than 50%. Your spitball is not a fit to real code. When I wrote "98% safe code" I meant the code that can be automatically verifi…

> If you're letting safe code in the same module as unsafe code mess with invariants, then the whole module needs to be verified by hand, and should be kept as minimal as feasible. Anything outside the module doesn't need to be verified by hand. More or less correct, but in principle, it also requires modules to have proper encapsulation and interfaces. Otherwise, an interface could be made that enables safe API func…

> But https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo... indicated that maybe up to 45 files include unsafe code. That is quite a lot of files. How many modules might that touch? How large are those modules?

I mean, you have the search results right there. You could always take the time to look for yourself instead of "wildly spitballing", especially since the codebase is not that large.

Might want to take a closer look at your search results anyways, since those results include the FAQ, the sudoers man page, and instances of #![forbid(unsafe_code)] and #![deny(unsafe_code)]. Not exactly a promising start...

But since you asked so nicely, by tokei's count and my transcribing file paths, the modules including the `unsafe` keyword account for ~39% (8207/21106) of the total lines of code in the repo. I don't think you'll need to actually look at anywhere near that amount of code, though; from a brief glance through the search results I suspect most of the `unsafe` usages are for FFI calls, and relatively self-documenting/self-contained ones at that. If there were modules with module-wide invariants, I do not appear to have stumbled upon them.

Re: Memory Safety

#69

Post by muricula »

websiteapi wrote: post #12
muricula wrote: post #10

Earlier quoted context omitted.

Usually people are talking about race conditions. When you say contrived you're thinking races conditions are difficult to win and unrealistic but attackers who have a lot of money on the line spend the time to win all sorts of wild race conditions consistently.

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?

Python has that property when you don't bring C extensions into the conversation. Data races exist, but can never cause memory corruption due to the GIL.

Re: Memory Safety

#70

Post by [deleted] »

crawshaw wrote: post #6
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.

I am not sure if you are: 1. attempting to retcon garbage collected languages as not memory safe, or 2. discussing a particular implementation choice of the standard Go runtime that was made because it is not a practical source of bugs (see https://research.swtch.com/gorace , it is not an inherent feature of the language, just the implementation, and it is the right practical choice) But either way: this is the sort…

[deleted]
Post reply on HN