6 ms·

Inline and Sideline Approaches for Low-Cost Memory Safety in C

101 points by matt_d 6y ago

uxp100 6y ago
Heh, this is a dissertation, and quite a bit to discuss. Maybe tomorrow there could be good discussion here. A few little nuggets of discussion: Section 2.1 seems like it could stand alone if you're looking for vocabulary and definitions about memory safety. Section 2.2 discusses type safety, and mentions C's weakness here. This is what most interests me about Rust, since the c software I spent several years working on did not contain any allocations, (I've had some short but confused conversations with rust evangelists, No, we don't malloc, we don't free, and unsafe exists on a different axis than if values put into DMA engines are sanitized). I don't think the run time solutions mentioned are the way to go, it really needs to be baked into the language, but some of these tools sound fun to play with. Section 5.4 talks about Unions. I was mistaken about the size of unions, which I thought always (or practically always) would be the size of the largest member, but the example given shows LLVM does not always behave that way, due to alignment requirements If I understand correctly.
- audidude 6y ago
  > Section 5.4 talks about Unions. I was mistaken about the size of unions, which I thought always (or practically always) would be the size of the largest member, The array'ability of the union is going to determine the size. So if you have a pointer at a given offset in one of the union'd structures it may need to increase the size of the union so that when used in an array the pointer will always stay aligned. (Same goes for any other type with alignment requirements).
- unanswered 6y ago
  Unless I'm missing something by skipping straight to 5.4, the explanation of unions is hot garbage. None of the examples are sane as they are all larger than the smallest array of a naturally-aligned type with the same alignment as the most-aligned field, such that this array is not smaller than the largest field in the union — which would be a structure with the same alignment and stride as the original union. (You could also "cover" it with a more precise struct which may be smaller than its own stride, which is what I think the paper was trying to explain, but the examples are still nonsense.)
yholio 6y ago
> Accepting that it is extremely difficult to achieve complete memory safety with the performance level suitable for production deployment I don't think this is true anymore even for system code. As Rust demonstrates, fat pointers and apropriate compile time restrictions ensure memory and type safety with marginal performance overhead. It's simply not a problem to bother with anymore in the 21st century, if not for the immense legacy of unsafe C/C++ code and the inertia of the industry and people.
- dig1 6y ago
  I would not say this is a solved problem - Rust is too young in the industry; let's wait and see. Java claimed it solved all memory-related issues, and some even stated good security because the programs were executed in VM. Many years later, we saw you could make memory leaks in Java, and you can escape VM. There is no inertia here but an expected outcome. C/C++ programs are often predictable, memory issues are easy to catch, and tooling is top-notch. Good luck with other languages, except maybe with JVM/.NET platforms.
  - MaxBarraclough 6y ago
    > C/C++ programs are often predictable, memory issues are easy to catch They are not. Memory-safety issues continue to impact major C/C++ codebases such as the Linux kernel and Chromium, sometimes manifesting as security vulnerabilities.
    - Alupis 6y ago
      I've been around long enough to know, given enough time, we'll find out Rust isn't the panacea to all our language problems - just like what the parent pointed out about Java and it's memory safety promises back in the day. It is indeed quite possible to write memory safe C/C++ code... and it's done every day. You never hear about how memory safe and performant all that code is... you only ever hear about the rare, high profile mistakes. The problems with languages like C++ are more about how bloated it's become. There's 30 ways to do anything in that language, and 24 of them you're not supposed to use anymore! This leads to all kinds of problems as more people touch the code over many years and C++ standards. I'm very interested in seeing Rust mature in this space... if not for memory safety promises, then for it being a "fresh start" for systems programming without all the legacy baggage C++ has.
a1369209993 6y ago
The actual file is at https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-954.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-954.pdf, not .html (and should be tagged [pdf] per https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html).
fortran77 6y ago
The C people don’t go into every discussion about Rust and make it about C.
- pjmlp 6y ago
  They are busy hunting for memory corruption issues bringing down a server in production.

101 points by matt_d 6y ago

Heh, this is a dissertation, and quite a bit to discuss. Maybe tomorrow there could be good discussion here. A few little nuggets of discussion: Section 2.1 seems like it could stand alone if you're looking for vocabulary and definitions about memory safety. Section 2.2 discusses type safety, and mentions C's weakness here. This is what most interests me about Rust, since the c software I spent several years working on did not contain any allocations, (I've had some short but confused conversations with rust evangelists, No, we don't malloc, we don't free, and unsafe exists on a different axis than if values put into DMA engines are sanitized). I don't think the run time solutions mentioned are the way to go, it really needs to be baked into the language, but some of these tools sound fun to play with. Section 5.4 talks about Unions. I was mistaken about the size of unions, which I thought always (or practically always) would be the size of the largest member, but the example given shows LLVM does not always behave that way, due to alignment requirements If I understand correctly.

audidude 6y ago
> Section 5.4 talks about Unions. I was mistaken about the size of unions, which I thought always (or practically always) would be the size of the largest member, The array'ability of the union is going to determine the size. So if you have a pointer at a given offset in one of the union'd structures it may need to increase the size of the union so that when used in an array the pointer will always stay aligned. (Same goes for any other type with alignment requirements).
unanswered 6y ago
Unless I'm missing something by skipping straight to 5.4, the explanation of unions is hot garbage. None of the examples are sane as they are all larger than the smallest array of a naturally-aligned type with the same alignment as the most-aligned field, such that this array is not smaller than the largest field in the union — which would be a structure with the same alignment and stride as the original union. (You could also "cover" it with a more precise struct which may be smaller than its own stride, which is what I think the paper was trying to explain, but the examples are still nonsense.)

yholio 6y ago

> Accepting that it is extremely difficult to achieve complete memory safety with the performance level suitable for production deployment I don't think this is true anymore even for system code. As Rust demonstrates, fat pointers and apropriate compile time restrictions ensure memory and type safety with marginal performance overhead. It's simply not a problem to bother with anymore in the 21st century, if not for the immense legacy of unsafe C/C++ code and the inertia of the industry and people.

dig1 6y ago
I would not say this is a solved problem - Rust is too young in the industry; let's wait and see. Java claimed it solved all memory-related issues, and some even stated good security because the programs were executed in VM. Many years later, we saw you could make memory leaks in Java, and you can escape VM. There is no inertia here but an expected outcome. C/C++ programs are often predictable, memory issues are easy to catch, and tooling is top-notch. Good luck with other languages, except maybe with JVM/.NET platforms.
- MaxBarraclough 6y ago
  > C/C++ programs are often predictable, memory issues are easy to catch They are not. Memory-safety issues continue to impact major C/C++ codebases such as the Linux kernel and Chromium, sometimes manifesting as security vulnerabilities.
  - Alupis 6y ago
    I've been around long enough to know, given enough time, we'll find out Rust isn't the panacea to all our language problems - just like what the parent pointed out about Java and it's memory safety promises back in the day. It is indeed quite possible to write memory safe C/C++ code... and it's done every day. You never hear about how memory safe and performant all that code is... you only ever hear about the rare, high profile mistakes. The problems with languages like C++ are more about how bloated it's become. There's 30 ways to do anything in that language, and 24 of them you're not supposed to use anymore! This leads to all kinds of problems as more people touch the code over many years and C++ standards. I'm very interested in seeing Rust mature in this space... if not for memory safety promises, then for it being a "fresh start" for systems programming without all the legacy baggage C++ has.

a1369209993 6y ago

The actual file is at https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-954.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-954.pdf, not .html (and should be tagged [pdf] per https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html).

fortran77 6y ago

The C people don’t go into every discussion about Rust and make it about C.

pjmlp 6y ago
They are busy hunting for memory corruption issues bringing down a server in production.