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

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • min-sized-rust

    πŸ¦€ How to minimize Rust binary size πŸ“¦

  • This repository contains information on how to achieve small Rust binaries: https://github.com/johnthagen/min-sized-rust

  • c2rust

    Migrate C code to Rust

  • 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

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • zz

    Discontinued πŸΊπŸ™ ZetZ a zymbolic verifier and tranzpiler to bare metal C [Moved to: https://github.com/zetzit/zz] (by aep)

  • > we'll find out Rust isn't the panacea to all our language problems

    I don't think anyone is suggesting it will be. It's not about to supplant Ada SPARK, for instance, as Rust is far behind in terms of formal analysis.

    > just like what the parent pointed out about Java and it's memory safety promises back in the day

    Java does address the memory-safety issues of C and C++. You can't have a buffer overflow vulnerability in pure Java code. You can't have any kind of undefined behaviour due to memory-management mistakes in your code. You can't double-free, or use-after-free, or deference a pointer to a local variable that has gone out of scope. You can't trigger undefined behaviour through a read-before-write bug in your code.

    It's possible to have a memory leak in Java, if you retain references to objects for too long, but that won't ever give rise to undefined behaviour.

    Of course, there can still be bugs in a JVM, but that's another matter. All languages are vulnerable to compiler bugs.

    Other languages like JavaScript do the same. It's possible to leak memory, but it's never possible to trigger undefined behaviour from JavaScript. That's a vital part of its security model.

    > It is indeed quite possible to write memory safe C/C++ code... and it's done every day

    That doesn't sound right.

    There's a reason I gave the examples of the Linux kernel and Chromium. They're written by highly competent developers, but they still have subtle memory-management bugs. Most C/C++ codebases are written by less competent developers, but are of far less interest to attackers, so it's of less consequence. Their memory-management bugs are likely to go unnoticed forever.

    I agree it's possible to write C/C++ code without memory-management bugs (there are various formal development systems for C), but it's a significant challenge. I'd hope avionics software, for instance, would be entirely free of such bugs.

    > You never hear about how memory safe and performant all that code is... you only ever hear about the rare, high profile mistakes.

    They're not that rare, they're a major source of serious security vulnerabilities, and languages like Safe Rust can close the door on them entirely.

    > 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!

    Agreed. C++ is quite a lumbering monster of complexity. Ada also has a reputation for being somewhat bloated, but it's not as far gone as C++.

    > if not for memory safety promises, then for it being a "fresh start" for systems programming without all the legacy baggage C++ has

    Keep an eye on Zig, too. Also D and Nim, and perhaps Vala. Also the lesser-known ZZ language, which looks very interesting.

    https://github.com/aep/zz

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts