The conceptualization of UB and memory unsafety as an immune system attack is the right one to use here, I think - “it attacks your ability to diagnose faults in the system”. In a “safety critical” system, it is the faults themselves that do the damage. Memory unsafety right-shifts the costs (from concept to design, from design to development, from development to testing, from testing to post-disaster investigations).

The thing about memory safety is that memory (un)safety is not a property directly related to functional safety (the product does not harm anyone), but one that increases the proof burden because it always needs to be taken into account. Potential memory unsafety in safety critical engineering is seen as a risk and a potential interference (where the behaviour of a system - memory allocation - may interfere with the behaviour of the system under inspection - e.g. your motor control), so eliminating it in general reduces your proof burden, but you are correct - it does only go to a certain extend.

For some insight into the risk that need to be mitigated around allocation from the perspective of the avionics standards, I co-wrote a paper about that recently: https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memory-Management-in-Ada-and-SPARK.pdf

I’d argue that up until these last few years, it was nuanced. The proving out of Rust has destroyed the nuance for all cases except assembler.

Not sure if you read all the way through, but the article mentions a few reasons where one might opt for less safety, mostly in the costs of all memory safety approaches.

It’s nuanced because the definition of memory safety depends on some abstraction for memory regions. Memory safety is a spectrum. An MMU enforces that every memory access must be to some valid memory. With a sanitizer-like approach, it means that every memory access is to a valid live object. In a typical programming language it adds a provenance model so every pointer is derived from a pointer to a valid object and any memory access via that pointer can only access the object and only for the lifetime of that object.

If you are implementing a memory allocator then a definition of memory safety that is built on top of an object model doesn’t really help because you are the thing responsible for providing the definition of an object. This is even more true for an OS kernel because you are providing the process abstraction and are responsible for page table setup. You can pretend that you have a language with object-level memory safety but anything that can modify page tables can bypass it and if most of your code pokes the page tables directly then you have no benefit. You need to understand what the benefits that you want from memory safety are, what is able to bypass memory safety, and how you limit the danger there.

Even if you are writing application code, C libraries can bypass language-level memory safety and the OS kernel can bypass everything (and needs to for I/O). You still need to think about what you’re getting from memory safety, whether it’s reducing cognitive load (I have a GC and plenty of RAM, I don’t need to think about lifetimes!), reducing bugs (my compiler errors if I write this, I don’t have to debug it!), or providing a strong security guarantee for isolating untrusted code (I can provide a plugin API without violating the integrity of data owned by my own code!).

Memory unsafety is a bug, the severity of which might depend, but it is always a bug.

Be careful what words you are choosing, because this sentence right there is false. Even though more likely than not you know everything I’m outlining below.

• A bug is when a program does not behave as desired. This includes crashes and security vulnerabilities.
• Something is unsafe when using it allows us to program bugs. A C function that dereference pointers they accept as argument are unsafe, because if we give them an invalid pointer we get Undefined Behaviour™, nasal demons…

For instance, this API is unsafe:

// Prints "Hello <name>!"
// Does nothing if name is NULL
void hello(const char *name)
{
	if (name == 0) return;
	printf("Hello %s!\n", name);
}

Because if the string I provide is not NULL terminated I’m going to run into trouble:

const char tom[3] = {'T', 'o', 'm', };
hello(tom);

The unsafety of hello() allowed the bug in user code. For hello() itself to have a bug, I need to make a mistake, such as forgetting the NULL check:

// Prints "Hello <name>!"
// Does nothing if name is NULL
void hello(const char *name);
{
	printf("Hello %s!\n", name);
}

C is dangerous and a huge source of bugs. But it is not itself a bug.

Likewise, walking a slackline in the mountain with no safety equipment is insanely dangerous, but you won’t die because of the line itself. Most likely it will be your inadequate competence, lack of attention, or hubris. (Nevermind adequate competence may be unattainable to begin with).

Note that the author worked in Google Earth team, and is speaking from experience.

I agree you should not trust input blindly, but it is a spectrum, isn’t it? I hope we can agree that memory safety is less important in Google Earth compared to Google Chrome. That’s all the author is saying.

I think by “take input from the user” he meant GUI events like click/drag/keystroke, which we can agree are pretty safe. (Mostly. I just remembered that “hey, type this short gibberish string into your terminal” meme that triggers a fork bomb…)

“Open this random PDF file” is technically a user event, but that event comes with a big payload of untrusted 3rd party data, so yeah, vulns galore.

Earth passed some pretty intense security reviews before it was launched and before every major feature release, and those security teams know their stuff.

Likely a big help was how well sandboxing works in WebAssembly, Android, and iOS.