Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development [pdf] (media.defense.gov)

Incremental replacement of critical dependencies also offers a practical migration path for large legacy codebases where complete rewrites are economically infeasible.

Memory safety is like the global warming of the software industry. Millions of careers depend on treating the problem and nobody wants the cure. I imagine Fil-C would be about as popular with the DoD as geoengineering / nuclear power are with environmentalists. Your project is so good that it's like a glitch in the matrix. Only people like Carmack and Musk are going to understand its value.

They're not going to mention a single-person experimental project that has 900 stars on GitHub.

This is meant to be a practical strategy that can be implemented nation-wide, without turning into another https://xkcd.com/2347

A definition of memory safety without data race freedom may be more precise but arguably less complete.

It is correct that data races in a garbage collected language are difficult to turn into exploits.

The problem is that data races in C and C++ do in fact get combined with other memory safety bugs into exploits.

A definition from first principles is still missing, but imagine it takes the form of "all memory access is free from UB". Then whether the pointer is in-bounds, or whether no thread is concurrently mutating the location seem to be quite similar constraints.

Rust does give ways to control concurrency, eg via expressing exclusive access through &mut reference. So there is also precedent that the same mechanisms can be used to ensure validity of reference (not dangling) as well as absence of concurrent access.

> More fundamentally, data races aren’t the thing that attackers exploit except when those data races do lead to actual memory corruption (like use after free, double free, out of bounds, access to allocator metadata etc).

This is absolutely not true. One of the classic data races is when you do a set of operations like this non-atomically:

  new_total = account.balance;
  new_total -= purchase_price;
  account.balance = new_total;

Which is a huge security vulnerability because it lets people double spend. Alice buys something for $1000 and something for $1 and instead of debiting her account by $1001 it debits it by $1 because the write for the second transaction clobbers the balance reduction from the first one.

Another common one is symbolic links. You check the target of a symbolic link and then access it, but between the check and the access the link changed and now you're leaking secrets or overwriting privileged data.

Data races are serious vulnerabilities completely independent of memory safety.

> Java and C# are mentioned as MSLs and yet they totally let you race.

In Java a data race means loss of sequential consistency. Humans generally don't understand programs which lack sequential consistency so a typical Java team probably can't debug the program, but the program still always has well defined behaviour - and chances are you don't want to debug the weird non-sequentially consistent behaviour anyway, you just want them to fix the data race.

In C# data races are not too dangerous for trivial objects which are valid for all bit patterns. If you race an integer k, well, now k is smashed, don't think too hard about the value of k, it does have some value but it won't go well for you to try to reason about the value. For a complex object like a hash table, it's Undefined Behaviour.

Meanwhile in C or C++ all data races are immediate UB, you lose, game over.

> because data races in the presence of memory safety are not a big deal from a security standpoint.

Note though that data races can make otherwise memory-safe programs not actually memory safe. See for example Go

It is also worth mentioning that not all memory safety vulns are exploitable or have a theoretical exploitation vector. Many these days are similar to theoretical crypto vulns in that "some day" the capability might be developed. It isn't just exploit mitigations but secure development practices that make it hard enough to where even theoretical exploitation isn't viable.

Probably because it has counted byte strings and does bounds checks?