Date: Wed, 31 Jan 2024 11:14:55 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Wojciech Puchar <wojtek@puchar.net> Cc: Antranig Vartanian <antranigv@freebsd.am>, Alan Somers <asomers@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Warner Losh <imp@bsdimp.com>, Scott Long <scottl@freebsd.org>, =?utf-8?Q?Goran_Meki=C4=87?= <meka@tilda.center> Subject: Re: The Case for Rust (in the base system) Message-ID: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> In-Reply-To: <a1a064e5-c968-b57-c87-f9fafac7bf@puchar.net> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <CAFF117C-4E6B-4339-8A9A-391ED720C508@freebsd.am> <a1a064e5-c968-b57-c87-f9fafac7bf@puchar.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 Jan 2024, at 10:15, Wojciech Puchar <wojtek@puchar.net> wrote: >=20 > The is no such thing as secure system programming language. While true in the absolute, that=E2=80=99s an unhelpful framing. = Different languages can eliminate different bug classes by construction. = The same is true of different APIs. For example, SQL injection attacks = are completely eliminated by APIs that present format strings, whereas = they are easy to introduce in ones that require you to construct an SQL = expression by string concatenation. For the languages under discussion, the key properties are memory = safety. Rust and modern C++ prevent a lot of bounds errors by carrying = bounds either in the type or as properties of a value and performing = explicit checks. More importantly, they provide abstractions such as = iterators, ranges, and views, which make bounds errors impossible by = construction because they use subset-like operators on valid ranges = derived from a collection and so ensure that every range that you = iterate over *must* be a valid subrange of the underlying collection. = They provide ownership semantics for pointers (in the language for Rust, = in the library via RIAA and smart pointers) than ensure that owning a = pointer prolongs its lifetime and so avoid temporal safety errors. Can a programmer get these things right without language support? = Absolutely, but each programmer has a finite budget for cognitive load. = In addition to thinking about memory management, they need to think = about good data structure design, efficient algorithms, and higher-level = security properties. The more attention that they have for these = things, the better their code is. We=E2=80=99ve seen this in some of = the Apple Silicon drivers for Linux, where writing them in Rust with = strong ownership types made it easy to implement some concurrent = algorithms that would be hard to get right in C and led to fast and = correct code. In terms of safe *systems* programming, I would regard the definition of = *systems* programming as programming that needs to step outside of a = language=E2=80=99s abstract machine. Memory allocators and schedulers, = for example, are in this category. These still benefit from richer type = systems (in snmalloc, as I mentioned previously in the thread, we model = the allocation state machine in C++ templates to ensure that memory = state transitions are all valid as memory moves between allocated and = the various states of deallocation), but the language cannot enforce = strong properties, it can at best provide the programmer with tools to = ensure that certain properties are always true in code that compiles. It=E2=80=99s up to you where you want to invest your cognitive budget, = but for code that runs in the TCB I=E2=80=99d rather we have as many = properties correct by construction as possible. David=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DCF4236-4DFA-448E-A378-DE04EC147B50>