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

On Tue, 23 Jan 2024 09:30:04 +0000
David Chisnall <theraven@FreeBSD.org> wrote:

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

I was more considering issues similar to abusing LD_PRELOAD before
running a setUID executable or uploading a php or python file into the
media portion of a website and then fetching it. Naive webserver
configurations tend to execute the uploaded code instead of just
serving the file. Think something similar to the big log4J disaster a
year or so ago. Eval is simply the cheapest and quickest way to screwup.

It looks like lua's import paths can be fairly well locked down in
embedded mode so a small shim might be needed then.