Date: Thu, 1 Feb 2024 00:07:34 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: David Chisnall <theraven@FreeBSD.org> Cc: Wojciech Puchar <wojtek@puchar.net>, 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>, Goran =?UTF-8?B?TWVracSH?= <meka@tilda.center> Subject: Re: The Case for Rust (in the base system) Message-ID: <20240201000734.83a86f486691276e533530e4@dec.sakura.ne.jp> In-Reply-To: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <CAFF117C-4E6B-4339-8A9A-391ED720C508@freebsd.am> <a1a064e5-c968-b57-c87-f9fafac7bf@puchar.net> <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 31 Jan 2024 11:14:55 +0000 David Chisnall <theraven@FreeBSD.org> wrote: > On 31 Jan 2024, at 10:15, Wojciech Puchar <wojtek@puchar.net> wrote: > > > > The is no such thing as secure system programming language. > > While true in the absolute, that’s 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’ve 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’s 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’s up to you where you want to invest your cognitive budget, but for code that runs in the TCB I’d rather we have as many properties correct by construction as possible. > > David First of all, NO MEMORY-SAFE language can write codes using volatile memory objects, most notably, memory-mapped I/O and/or DMA driver. I formerly thought "Rust should NOT be able to write one by itself only, as Rust guys states it's memory-safe". But I huppened to know "unsafe" keyword to allowing such a thing. So I come to consider Rust as non-memory-safe. Evil programmer CAN ABUSE THE MECHANISM. Recall what happened to Linux kernel by UMN. [1] [2] Even using Rust, memory safety is ON HUMAN. Rust should have NOT introducing such a functionality and let them be kept on C and/or assembler codes to be called. This way, C/assembler could have been focused upon left C/assembler codes only about memory-safety. Yes, there can be memory-mapped I/O devices which completely divide addresses it uses for input and output. In such devices, "unsafe" keyword should be needed at all IN THEORY, but hardware/firmware bugs and intentional backdoors could overrun the buffer on write. Keeping these in mind, Rust would be EASIER to write memory-safe codes than C/assembler. What are problems of Rust-in-Base, I think, are that *Differences of philosophy. Unix and its delivetives, of course including FreeBSD base, is based on simplicity and memory/disk efficiency, notably uses of shared objects (*.so). Reuse / share everything immutable anywhere. In contrast with it, Rust persons prefer "sharing source codes as crates but do NOT share compiled objects". IIUC, if crate A is used on crate B and C, and crate B is used by crate D, usually crate D is built with crate A and B included. Then, if crate C and D is required by crate E as dinamically loadable module (the API/ABI changes when Rust itseld is updated, thus basically required full rebuild to link as native Rust objects), crate A and B are duplicated when object created from crate E are loaded. In these cases, all of crate A, B, C, D and E should be build as dynamically linked object and avoid duplicates. *API/ABI instability within Rust versions. But IIUC, this would be avoided if built with --crate-type=cdylib. We should force this unless the whole codes of FreeBSD are rewritten with Rust only. No moving goal is wanted for not-enough-large projects. *crates. All crates needed for FreeBSD base SHALL be BSD-compatiblly licensed and allowed to fork to commit to FreeBSD src tree. Every other crates need to be REIMPLEMENTED BY OURSELVES WITH CLEAN ROOM DEVELOPEMENT. *CPU consumption of rustc. For anyone not having dedicated build computer like me, if any of poudriere jail stard building Rust codes, the computer on hand becomes unresponsive/unusable, as ALL EXISTING CORES ARE EATEN UP. This would possibly fixed/relaxed once sched_ule is overhauled or new scheduler which can avoid this is implemented. At least for now, 6C12T core processor is not at all enough for Rust. [1] https://www.bleepingcomputer.com/news/security/linux-bans-university-of-minnesota-for-committing-malicious-code/ [2] https://www.reddit.com/r/HobbyDrama/comments/nku6bt/kernel_development_that_time_linux_banned_the/ -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240201000734.83a86f486691276e533530e4>