Re: The Case for Rust (in the base system)

On 22 Jan 2024, at 22:54, Robert R. Russell <robert@rrbrussell.com> wrote:
> 
> If you had to estimate what is the cost of enforcing better C++ code?

For CHERIoT RTOS, we use clang-tidy to run the static analyser.  It’s the longest CI job, by quite a large margin, but it’s a small enough project that we haven’t felt the need to trim what it runs on, so we run it on *every* file on every commit to a PR.  

It’s also something that you need to do from the start.  If you run the clang analyser or Coverity on FreeBSD, you get a vast number of false positives and so having a ’no warnings’ policy is impossible to enforce.  I would recommend doing it on a per-compilation-unit basis:

 - New files must have no new warnings.
 - Old files get opted in once they’re clean and must then have no new warnings.
 - Anything that explicitly silences a false positive needs sign-off from two committers in code review.

At the very least, the last point will likely get the comment ratio up a bit, since the code will need to actually be readable by other people to make it into the tree.

Even then, there’s likely to be a bit of churn when you update to newer versions of the analysers.

Making this work really just needs build system infrastructure to generate a compile_commands.json (something that any build system that isn’t Make can do. I know MaskRay has written some scripts to try to generate one from bmake but I couldn’t get them to work) and some work from the CI team.  They’re currently understaffed and under-resourced.  

> I am not familiar with Lua and most of my experience with Lua like
> languages have included dynamic code injection as an attack vector. Is
> it feasible to protect Lua from that problem in the use case you
> propose?


Yes.  Don’t call `eval` on untrusted input.

David