Date: Tue, 23 Jan 2024 09:10:40 -0600 From: "Robert R. Russell" <robert@rrbrussell.com> To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: <20240123091040.18c4ffcf@venus.private.rrbrussell.com> In-Reply-To: <FE03DCC4-7F80-4258-B371-EA3FCD14AF9B@FreeBSD.org> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <1673801705774097@mail.yandex.ru> <CANCZdfpqWgvV_RCvVO_pvTrmajQFspW%2BQ9TM_Ok3JrXZAfeAfA@mail.gmail.com> <ef4ad207-5899-42b6-8728-bc46f1417e9e@antonovs.family> <202401210751.40L7pWEF011188@critter.freebsd.dk> <40bc1694-ee00-431b-866e-396e9d5c07a2@m5p.com> <CAOtMX2hppfdu5ypDdGpfw_QDcd1rwJEeyVfSk9ogFEm7CiV6Kw@mail.gmail.com> <C5FC83ED-25BC-44AF-BD20-E0E5F5BC64FE@FreeBSD.org> <20240122165452.13733a66@venus.private.rrbrussell.com> <FE03DCC4-7F80-4258-B371-EA3FCD14AF9B@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240123091040.18c4ffcf>