Date: Wed, 31 Jan 2024 15:50:40 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> 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>, =?utf-8?Q?Goran_Meki=C4=87?= <meka@tilda.center> Subject: Re: The Case for Rust (in the base system) Message-ID: <782FA00C-3B90-49C8-85F7-AF784F42A3CC@FreeBSD.org> In-Reply-To: <20240201000734.83a86f486691276e533530e4@dec.sakura.ne.jp> 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> <20240201000734.83a86f486691276e533530e4@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 Jan 2024, at 15:07, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> = wrote: >=20 > First of all, NO MEMORY-SAFE language can write codes using volatile > memory objects, most notably, memory-mapped I/O and/or DMA driver. The first half of that is obvious nonsense. Memory-mapped I/O is not = intrinsically unsafe, from a memory-safety perspective. Even Java has = volatile objects and Sun Labs used Java for device drivers twenty years = ago. Having a memory-safe interface for MMIO is helpful. With another hat, I am the maintainer of CHERIoT RTOS, which uses = hardware-enforced memory safety for all code, including RTOS code. All = of our drivers do direct MMIO and are memory safe. DMA is in the category of things that I class as real systems = programming because it sits below the level of the language abstract = machine and so *is* able to violate the guarantees. Even in C; however, = the busdma framework tries to make this safe: you are not *supposed to* = DMA to and from arbitrary memory. A strong type system can enforce = this. > 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. Correct, for things that are real systems programming tasks, you need to = poke holes in Rust=E2=80=99s abstract machine via the unsafe keyword. = These come with an implicit contract that *you* are now responsible for = enforcing those rules at the boundary. For a DMA interface, for = example, a Rust equivalent of the busdma framework would provide objects = that encapsulate valid DMA mappings whose lifetime manages IOMMU = entries. These would be passed into unsafe blocks for DMA operations. = Within those blocks, you could still violate memory safety, but the code = review required to ensure that you don=E2=80=99t is entirely local = reasoning. > 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] A malicious programmer, whose code is not reviewed properly or who = manages to sneak in bad code, can break out of the type system for Rust. = In contrast, a C programmer whose attention drifts for a few seconds = while typing can do the same thing. > 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. I don=E2=80=99t understand the rationale here. FFI in Rust, due to the = tight coupling, needs to be unsafe. Whether your unsafe language is a = subset of Rust or is purely FFI code, it still exists. If it=E2=80=99s = a subset of Rust, then it=E2=80=99s easier to review because it=E2=80=99s = in context and can operate over Rust types. > 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. This is specific to MMIO devices *that initiate DMAs* > Keeping these in mind, Rust would be EASIER to write memory-safe codes > than C/assembler. Correct. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?782FA00C-3B90-49C8-85F7-AF784F42A3CC>