C can be memory safe, part 2

This post from last year was posted to a forum, so I thought I’d write up some rebuttals to their comments.

The first comment is by David Chisnall, creator of CHERI C/C++, which proposes we can solve the problem with CPU instruction set extensions. It’s a good idea, but after 14 years, CPUs haven’t had their instruction-sets upgraded. Even mainstream RISC V processors haven’t been created using those extensions.

Chisnall: “If your safety requires you to insert explicit checks, it’s not safe“. This is true from one perspective, false from another. My proposal includes compilers spitting out warnings whenever bounds information doesn’t exist.

C is full of problems in theory that doesn’t exist in practice because the compiler spits out warnings telling programmers to fix the problem. Warnings can also note cases where programmers probably made mistakes. We can’t achieve perfect guarantees, because programmers can still make mistakes, but we can certainly achieve “good enough”.

Chisnall: ….tread safety….. I’m not sure I full understand the comment. I understand that CHERI can guarantee atomicity of bounds checking, which would require multiple (interruptible) instructions otherwise. The number of cases where this is a problem, and the C proposal would be no worse than other languages like Rust.

Chisnall: Temporal safety…. A lot of Rust “ownership” techniques can be applied to C with these annotations, namely, marking which variables OWN allocated memory and which simply BORROW it. I’ve reviewed a lot of famous use-after-free and double-free bugs, and most can be trivially fixed by annotation.

Chisnall: If you are writing a blog never having actually tried to make large (million line or more) C codebases memory safe, you probably underestimate the difficulty by at least one order of magnitude. I’m both a programmer who has written a million lines of code in my lifetime as well as a hacker with decades of experience looking for such bugs. The goal isn’t to pursue the ideal of 100% safe language, but of getting rid of 99% of safety errors. 1% less safe makes the goal an order of magnitude easier to reach.

snej: This post seems to epitomize the common engineer trait of seeing any problem you

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.

This article has been indexed from Errata Security

Read the original article: