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

81–90 of 162 posts

Re: Memory safety is necessary, not sufficient

#81

Post by kazinator »

moody__ wrote: post #74
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…

>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. This is true and when your compiler actually abides by these values it is shocking how many issues just go away. The problem is that gcc and clang are nowhere near a simple implementation, asking the question of how exactly gcc or clang arrived at some given assembly for some giv…

> piece of software be simple than that it be correct

Here is the thing: which of these is more plausible or at least less far-fetched?

A. Write a program that is not correct now, but will eventually be.

B. Write a program that is complicated now, but will eventually be simpler.

:)

Simplicity isn't something you can leave out now and add later, yet correctness can often be treated that way. Even a shop that values correctness above all else still does debugging. (If not code, then debugging their proofs, and debugging whether their formal specification actually implement the functional requirements).

Re: Memory safety is necessary, not sufficient

#82

Post by kazinator »

moody__ wrote: post #74
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…

>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. This is true and when your compiler actually abides by these values it is shocking how many issues just go away. The problem is that gcc and clang are nowhere near a simple implementation, asking the question of how exactly gcc or clang arrived at some given assembly for some giv…

The main problem is this: the undefined status of one construct A in the program changes the behavior of a different, independent construct B in the program, even in cases when, say, B executes first and is correct. Everything is jumbled together in the optimizer, which establishes logical ties between the pieces that are unrelated to the network of intent.

If the undefined behavior of construct A causes just A to misbehave, we are still in sane waters.

Re: Memory safety is necessary, not sufficient

#83

Post by the_gipsy »

kazinator wrote: post #81
moody__ wrote: post #74

Earlier quoted context omitted.

>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. This is true and when your compiler actually abides by these values it is shocking how many issues just go away. The problem is that gcc and clang are nowhere near a simple implementation, asking the question of how exactly gcc or clang arrived at some given assembly for some giv…

> piece of software be simple than that it be correct Here is the thing: which of these is more plausible or at least less far-fetched? A. Write a program that is not correct now, but will eventually be. B. Write a program that is complicated now, but will eventually be simpler. :) Simplicity isn't something you can leave out now and add later, yet correctness can often be treated that way. Even a shop that values co…

If you simplify a correct program, it will most likely still be correct. If you "correct" a simple program, it probably becomes complicated.

Re: Memory safety is necessary, not sufficient

#84

Post by moody__ »

kazinator wrote: post #81
moody__ wrote: post #74

Earlier quoted context omitted.

>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. This is true and when your compiler actually abides by these values it is shocking how many issues just go away. The problem is that gcc and clang are nowhere near a simple implementation, asking the question of how exactly gcc or clang arrived at some given assembly for some giv…

> piece of software be simple than that it be correct Here is the thing: which of these is more plausible or at least less far-fetched? A. Write a program that is not correct now, but will eventually be. B. Write a program that is complicated now, but will eventually be simpler. :) Simplicity isn't something you can leave out now and add later, yet correctness can often be treated that way. Even a shop that values co…

You add in simplicity by taking out code. It is very possible (and common) to find better abstractions or methods to approach a problem that reduce the complexity of the code.

Re: Memory safety is necessary, not sufficient

#85

Post by kazinator »

moody__ wrote: post #84
kazinator wrote: post #81

Earlier quoted context omitted.

> piece of software be simple than that it be correct Here is the thing: which of these is more plausible or at least less far-fetched? A. Write a program that is not correct now, but will eventually be. B. Write a program that is complicated now, but will eventually be simpler. :) Simplicity isn't something you can leave out now and add later, yet correctness can often be treated that way. Even a shop that values co…

You add in simplicity by taking out code. It is very possible (and common) to find better abstractions or methods to approach a problem that reduce the complexity of the code.

It is vanishingly uncommon to simplify an entire application, so that it goes from something complex to something whose number one value is simplicity, such that the simplicity is reflected in the actual functional specification.

Re: Memory safety is necessary, not sufficient

#86

Post by jiggawatts »

jules wrote: post #76
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…

Undefined behavior is critical for performance. Without undefined behavior, C compilers would not be able to optimize at all. You'd be running everything at -O0 or worse.

Undefined behaviour enables only a fairly small set of optimisations. There's a large set of optimisations that can be implemented completely safely without having to make such dangerous assumptions. Other programming languages do this all the time, it's not just C/C++ that have optimisers!

Re: Memory safety is necessary, not sufficient

#87

Post by kazinator »

the_gipsy wrote: post #83
kazinator wrote: post #81

Earlier quoted context omitted.

> piece of software be simple than that it be correct Here is the thing: which of these is more plausible or at least less far-fetched? A. Write a program that is not correct now, but will eventually be. B. Write a program that is complicated now, but will eventually be simpler. :) Simplicity isn't something you can leave out now and add later, yet correctness can often be treated that way. Even a shop that values co…

If you simplify a correct program, it will most likely still be correct. If you "correct" a simple program, it probably becomes complicated.

If you algebraically simplify a correct program it will be correct.

But the simplicity which is at play in the context of "worse is better" is simplicity of requirement specifications themselves, before any code is written. (I think I'm the one who muddied the waters here by insinuating that correctness is a matter of debugging an incorrect program against a correct specification.)

In projects that value simplicity over correctness, what that means is that what is considered correct (as in the requirement we shall implement) is the simpler requirements, which are regarded as incorrect by other projects.

Programs that implement the complex requirements are vanishingly improbable to be simplified into programs that implement simple requirements, simply because those are breaking changes.

E.g. you can't take a database engine that provides certain consistency guarantees and make it have weaker guarantees in the next version (for the sake of simplicity), without breaking all the applications that depend on the current guarantees.

Correctness can be added --- including at the requirements level, not only debugging. It can be because it's often backwards compatible. E.g. adding handling for cases that were previously ignored.

Re: Memory safety is necessary, not sufficient

#88

Post by jiggawatts »

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…

> the vast majority of firefox crashes I experience now are rust panics

Have you considered that this might be precisely because Rust is catching and stopping something bad with a safe panic? And that the same programmer making the same mistake in C/C++ would have resulted in silent data corruption, a security vulnerability, and possibly a portal into the space between dimensions from which optimising compilers will happily allow the Others into our world because -- and I quote -- "that's allowed by the spec"?

I often see in the news some panic about a sudden rise in some rare disease, but it almost always turns out that the increase is just due to an improvement in detection, not a change in the actual prevalence.

I suspect that silent data corruption vs liberal use of asserts that trigger visible panics is in the same category.

Someone in this thread was complaining that they think exceptions are "dangerous" and gotos are "safe". Their thinking is probably coloured by endless stack traces from exceptions in managed languages, comparing that to the "oops I stepped over a mandatory cleanup using goto" in their own C code, which they probably won't even notice... because it's probably just silently leaking memory. Or file handles. Or threads. But not loudly and in your face!

Re: Memory safety is necessary, not sufficient

#89

Post by renox »

jules wrote: post #76
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…

Undefined behavior is critical for performance. Without undefined behavior, C compilers would not be able to optimize at all. You'd be running everything at -O0 or worse.

Where's your proof?

Rust has far fewer UB than C yet its performance is comparable to C.

Re: Memory safety is necessary, not sufficient

#90

Post by weinzierl »

SnowflakeOnIce wrote: post #79
tptacek wrote: post #35

I'm not sure I understand what this piece is trying to say about Python memory safety. Conventionally, in software security, Python is considered a memory-safe language. The piece makes the case that Python isn't memory safe when you FFI into a C library. But neither is Rust, nor is it when you use `unsafe`. What matters in both case is how little unsafe code you end up writing. Memory safety is a software security c…

> Conventionally, in software security, Python is considered a memory-safe language. The piece makes the case that Python isn't memory safe when you FFI into a C library. Interesting and largely unknown trivia: it's possible to invoke memory errors in the underlying C interpreter from pure Python code — no libraries and no imports needed! One way of doing this is by creating new `code` objects with crafted bytecode.…

Is this because of a bug and might be fixed in the future or is it considered an unavoidable consequence of some design decision and will stay that way for the foreseeable future?

From what I understand about Rust, if something similar was possible in safe Rust it would be considered a bug and eventually fixed.

Post reply on HN