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

Memory safety is necessary, not sufficient

steveklabnik.com

Post reply on HN
Print view View original

51–60 of 162 posts

Re: Memory safety is necessary, not sufficient

#51

Post by lll-o-lll »

tptacek wrote: post #50
lll-o-lll wrote: post #49

Earlier quoted context omitted.

OK, but I think you are moving the goal posts. You referred to “data races” and “security exploits” and suggested the two were not related. Memory corruption is only one (small) class of security exploits. Data races cause just as many in process, in memory, exploits as multi-step file operations (we are talking breaking application security models). Perhaps Rust can prevent most of these! (I don’t know rust).

What are they? Show me the vulnerabilities you're talking about. I don't think I'm moving the goalposts here. The major distinction between Rust and (say) Java is Rust's type system formalisms to prevent in-process data race memory corruption. Those are real features, but they don't mitigate a major class of vulnerabilities.

Any multi-step code, e.g. AddUser(); SetPermissions();

But, fair enough, this is not what you were talking about, and I reacted to something you weren’t intending to convey.

Re: Memory safety is necessary, not sufficient

#52

Post by mlinksva »

amelius wrote: post #22

Our programs are growing so big by having so many (indirect) dependencies that we need a way to sandbox the libraries that we include from our main programs. This is the type of safety that I'm looking for, really.

I've been idly wondering, what is the relationship between memory unsafety, or more generally, undefined behavior, and ambient authority? For security purposes, is the former a special, unintended (for the most part, it's a bug) form of the latter?

Re: Memory safety is necessary, not sufficient

#53

Post by humanrebar »

mannuch wrote: post #11

I wonder what the author thinks about Swift’s new C++ interop story? Since the Swift compiler includes Clang, and can thus compile both your C++ and Swift into LLVM IR, without the need for an FFI later between the two, couldn’t this be the “Typescript for C++” that the author points out a space for? The Swift folks are very much thinking about Swift as a C++ successor that can be incrementally migrated to so I’m a b…

Swift is an interesting option, though that interop requires dropping support for non-clang toolchains, and I don't see that happening any time soon. I mean, it makes sense for code that exclusively targets Apple platforms, and maybe that's all that Apple and the Swift team care about?

Re: Memory safety is necessary, not sufficient

#54

Post by armchairhacker »

dgreensp wrote: post #19

I think it’s worth emphasizing that the C spec’s love of undefined behavior—if you do X by accident, anything can happen—and the apparently massive amount of memory-unsafe software that has been written that will just allocate 16 bytes on the stack and then read from a file descriptor until it encounters a null byte… are examples of things that aren’t considered remotely sane or reasonable to a modern programmer or l…

> If you read the essay, it says “worse is better” means (paraphrasing) it’s more important that C compilers be easy to implement than easy to use. Also, it is more important that the implementation—or the design of the implementation—of a piece of software be simple than that it be correct. It is more important that it be simple than that it be consistent. It is more important that it be simple than that it be “complete” (for example, handle edge cases; it just needs to work in “most situations”).

This is really ironic considering C++, whose compilers may literally be the most complicated compilers to ever exist, and none of them implement the full (C++23) language spec.

What kind of maxim does C++ go by?

Re: Memory safety is necessary, not sufficient

#55

Post by klabb3 »

nullc wrote: post #42
Ar-Curunir wrote: post #32

Earlier quoted context omitted.

> As a result, I don't think it can be taken for granted that rust as a whole is an advancement in software integrity-- it may be, but it's something that ought to be formally studied. In some cases rust might be replacing memory safety bugs with an even greater number of other defects which, depending on the application, may be worse. I’m sorry, but without any supporting evidence for this claim, this is just FUD. E…

Citation welcome to those case studies, because I've not seen them. It's on the advocates of rust to establish that it makes things better because it absolutely isn't unambiguous. We really seem to be in the stone age in terms of what practices lead to higher quality software. We still have people who chant "goto harmful" against one simply forward jumps to on-error-cleanup code, yet still litter their C++ and java w…

I appreciate your comments in this thread. They are a healthy skeptical technology-neutral take unaffected by novel-paradigm-dogma – in this case about Rust, but it really applies to any software practice. I have nothing against Rust and I believe it has advanced the space of mainstream imperative languages significantly, particular in high performance low-level coding. But you have to always keep an eye on the horizon.

> We really seem to be in the stone age in terms of what practices lead to higher quality software.

I agree. What I always come back to is simplicity, or reducing total cognitive complexity. The only way I know of that actually consistently works, is modularization (in the most liberal sense of the word), in order for our human brains to work in a reduced problem domain at any given point in time. So whatever languages, protocols, tooling and design patterns help with that, I lean into, although this is (currently) a subjective measure.

On some problems, it’s clear Rust is amazing in this respect, taking away certain worries so that you can focus on “what matters”. But this is not a truism in all domains, because the issues that Rust addresses are merely a good list, not an exhaustive one.

Re: Memory safety is necessary, not sufficient

#56

Post by mannuch »

steveklabnik wrote: post #13
mannuch wrote: post #11

I wonder what the author thinks about Swift’s new C++ interop story? Since the Swift compiler includes Clang, and can thus compile both your C++ and Swift into LLVM IR, without the need for an FFI later between the two, couldn’t this be the “Typescript for C++” that the author points out a space for? The Swift folks are very much thinking about Swift as a C++ successor that can be incrementally migrated to so I’m a b…

I do not know a ton about it. Thanks for the pointers. I kept up with Swift more in the old days, but it doesn't seem to have gained a ton of relevance outside of Apple platforms, which I don't develop for. Doesn't mean that I think that it's bad, just that that's why I haven't spent a lot of time with it yet.

For sure! Yeah I think a lot of people don’t realize that there’s actually a ton of really interesting work going on in Swift that is very relevant to the current conversation around languages these days (i.e. memory safety, data race safety, performance, development experience, etc.)

The cross-platform story is getting quite good with Swift, but I think a lot of people just aren’t aware of it. Linux support is good and Windows is getting better and better.

For example, The Browser Company is betting big on using Swift for its Windows app and talks about why they are doing it https://open.substack.com/pub/speakinginswift/p/interoperabi...

Re: Memory safety is necessary, not sufficient

#57

Post by eschaton »

armchairhacker wrote: post #54
dgreensp wrote: post #19

I think it’s worth emphasizing that the C spec’s love of undefined behavior—if you do X by accident, anything can happen—and the apparently massive amount of memory-unsafe software that has been written that will just allocate 16 bytes on the stack and then read from a file descriptor until it encounters a null byte… are examples of things that aren’t considered remotely sane or reasonable to a modern programmer or l…

> If you read the essay, it says “worse is better” means (paraphrasing) it’s more important that C compilers be easy to implement than easy to use. Also, it is more important that the implementation—or the design of the implementation—of a piece of software be simple than that it be correct. It is more important that it be simple than that it be consistent. It is more important that it be simple than that it be “comp…

1. If you don’t use a language feature in your code, your code shouldn’t pay the cost—no matter what else might be helped, enabled or prevented by that. To this day compilers let entire features like exceptions and RTTI be disabled entirely rather than accept that there might possibly be some costs worth imposing.

2. Binary compatibility and dynamic linking don’t matter at all, and shouldn’t ever be considered in design or revision of anything language-related.

3. All areas of computer science and engineering are open to being a part of the standard library and existing language and standard library authors are the best judges of what should be in the standard and how it should be implemented than anyone else, including platform vendors or subject matter experts.

Re: Memory safety is necessary, not sufficient

#58

Post by [deleted] »

pornel wrote: post #6

I think it's underappreciated that Rust's `unsafe{}` doesn't exist in isolation. Rust has facilities for building safe abstractions on top of it, and has a culture of taking this abstraction layer seriously. Danger of unsafe features and FFI is usually conditional — you can use a pointer only until some point, or only on a single thread, etc. A use of unsafe in Rust doesn't become "be careful!" kryptonite spreading a…

[deleted]

Re: Memory safety is necessary, not sufficient

#59

Post by couchand »

lmm wrote: post #40
Ygg2 wrote: post #37

Earlier quoted context omitted.

> If you at all break the rather subtle rules, then essentially anything can and will happen. If by subtle rules you mean your invariants, that is missing fundamental assumptions. It's akin to making a building without foundation and load bearing structures. > So for example, there was recently a thread where someone had code that checked if a value was in range to safely coerce it directly to an enum then did so. Bu…

> If by subtle rules you mean your invariants, that is missing fundamental assumptions. > It's akin to making a building without foundation and load bearing structures. That's exactly how C approaches UB too. > However note the UB goes away if you never use any unsafe code. Or if you expand your unsafe to encompas some safe code. Right. The problem is that's untenable; any nontrivial program will have unsafe somewher…

> If Rust doesn't give you more and better support in doing that than C does, then it's not really making a difference.

It does and if you've been missing that you've misunderstood this whole discussion. Rust allows you to wrap up some unsafe code in a safe abstraction. You use the type checker to enforce your invariants, such that the unsafe code can be reviewed in isolation.

Rust gives you exactly what you're saying you want. Steve is describing Rust as it is.

Re: Memory safety is necessary, not sufficient

#60

Post by wavemode »

dgreensp wrote: post #19

I think it’s worth emphasizing that the C spec’s love of undefined behavior—if you do X by accident, anything can happen—and the apparently massive amount of memory-unsafe software that has been written that will just allocate 16 bytes on the stack and then read from a file descriptor until it encounters a null byte… are examples of things that aren’t considered remotely sane or reasonable to a modern programmer or l…

Software was significantly simpler in those days. I don't find it strange that they took a simplified view of software engineering. Specifically because those exact same simplified views still exist today - talk to people who've never worked on large complex systems, and you will usually encounter similar "anti-perfectionism".

People adopt simplified engineering practices when working on simple software by themselves, compared to when working on complex software within a large team.

Post reply on HN