[HN Gopher] Inline and Sideline Approaches for Low-Cost Memory S...
___________________________________________________________________
Inline and Sideline Approaches for Low-Cost Memory Safety in C
Author : matt_d
Score : 85 points
Date : 2021-02-17 13:28 UTC (7 hours ago)
(HTM) web link (www.cl.cam.ac.uk)
(TXT) w3m dump (www.cl.cam.ac.uk)
| a1369209993 wrote:
| The actual file is at 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).
| yholio wrote:
| > 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.
| Animats wrote:
| Yes. We really need a usable C to Rust translator. The existing
| "transpilers" just turn C with pointer arithmetic into Rust
| with pointer arithmetic. The output is awful.[1]
|
| This is a hard problem, but not impossible. There are people
| who say it's impossible. The usual excuses are obfuscated code,
| undecidablity, need to maintain binary compatibility, etc.
| Those are not show-stoppers. What's needed is something that
| converts C to ideomatic safe Rust most of the time, and to fat-
| pointer slow but safe Rust when the converter can't figure out
| what the code is doing.
|
| This is a job comparable to an optimizing compiler, and that's
| a big project. It will take money.
|
| More detailed comments on Rust forums: [2]
|
| Trying to patch up C is not promising. It's been tried, many
| times. The thesis shows most of the approaches that have been
| tried. GCC used to have a "fat pointer" option with checking,
| but it was rarely used, and has, I think, been deprecated.
| Putting extra info in the high bits of pointers has been tried.
| Memory allocation where all allocations in a block are the same
| size and you can look up the size of by block has been tried.
| Syntax changes to C have been proposed; I've been down that
| road.
|
| [1] https://c2rust.com/
|
| [2] https://users.rust-lang.org/t/c-to-rust-translator/55381/14
| dig1 wrote:
| 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.
| Alupis wrote:
| Not to mention binary size too.
|
| The same program written in Rust can be magnitudes larger in
| binary size[1], which is a complete non-starter for many
| embedded projects (where a _lot_ of C /C++ code is destined
| to live).
|
| [1] https://dev.to/aakatev/executable-size-rust-go-c-
| and-c-1bna
| MaxBarraclough wrote:
| > 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 wrote:
| 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.
| uxp100 wrote:
| 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.
| unanswered wrote:
| 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.)
| audidude wrote:
| > 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).
___________________________________________________________________
(page generated 2021-02-17 21:01 UTC)