From nobody Wed Jan 31 11:14:55 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TPzwF14K4z57YFm for ; Wed, 31 Jan 2024 11:15:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TPzwF0b4Fz4PKt; Wed, 31 Jan 2024 11:15:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706699709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L/HmiDCWCLVCiSZ5qVHOgRzt9CHci3WqDSs/9UHJPx8=; b=Y7BdZYwsBt+meTHuZrUYC1Pcx3ndZ8RHwFeJSVdZqTpEql1KJ8fRkGX9fVKSRBaYuuh3/4 VZzHDgrm8g3XCYyqv6uOyUXdFCL6h9murfN/yzzq9nz4a4IOrWFfzkwuPvHCahnIZiap5j fn8YIqWdhnM/4kirFiBIKYfZnKq8OjXwhArpscFtsExE+67voleVXXnny5Y56ay+KjOcWI HIYHqpa1FhefQgPk9d/yDSIrhwTDnA2CN05E4RxIusNCHS2iJa3sxupUSzbtF7VljYLiQf jHXCfPAmpGu0r4eGNdM2Myd/HNQh5ce73uW7fQwGbl02HMHwKgrbbJXAW+pieQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706699709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L/HmiDCWCLVCiSZ5qVHOgRzt9CHci3WqDSs/9UHJPx8=; b=pRuakbBV0h0pS/ckwjP3nkEWq4Fctj3chbkKAt597Xxv2pEL9gzs2iWv2uDyPBM8ymObUO SswXfSCKcmGxPlpShpbHi3mk5uYXkvPNuOyMl4EQsYe/U1KN7dYwSw45UHjyd+7rsRyEj+ qMCkwRS6SSH2Pbbhrvaz1Ss6agxG1kcxT3uqqWj/xqihxRSTiykxY6AIwQiqP+32eCtIZ6 oNjLuAH92BhZIinpiiwmdYk2rZurLpPJ3lcfrGx/G7W5V+gK8QBfVeiqcgAvSEGrb2B85m oWdcw0+QfwzQnO+R/OoBDIW2I9LIHVlo8N9cif/xZ3l3zSwf8Aiukfzmi4sY4g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706699709; a=rsa-sha256; cv=none; b=nwP3vctXGdregCq2f5Qzfsn3w9tUQGHChqdBu0xGx5wyfQUkQW3BIxMbECVmySq3UVV5fn ooMSypXB6nevDGX2Omg6KHbzeo9ySM3BCB36eQG9Fqgag3V9Fdd0/2v4d9S5Ij3r64MaiB 4F8RNCn/grFJTQT3/zp2tvMRrj4q8vj/XnsXBUUtmbYxyMiqEnz0FcRoxbG3WzpfNt36Kl hTeiUexkzp6pYsgEaGN+DUy33nWmL7v4ar6tCT8ELoRUfJd/6bbClzC4H/KtZdMXekHjYb j0TnCd7fUbLHFhTsU8ananimnFkWDbrRcysozW3pDTC4r7lnfh6T/kO8pnevMA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TPzwD6bzyzbqY; Wed, 31 Jan 2024 11:15:08 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-153-95-118.range109-153.btcentralplus.com [109.153.95.118]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 26E74C0A7; Wed, 31 Jan 2024 11:15:07 +0000 (GMT) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: The Case for Rust (in the base system) From: David Chisnall In-Reply-To: Date: Wed, 31 Jan 2024 11:14:55 +0000 Cc: Antranig Vartanian , Alan Somers , FreeBSD Hackers , Warner Losh , Scott Long , =?utf-8?Q?Goran_Meki=C4=87?= Content-Transfer-Encoding: quoted-printable Message-Id: <3DCF4236-4DFA-448E-A378-DE04EC147B50@FreeBSD.org> References: To: Wojciech Puchar X-Mailer: Apple Mail (2.3774.200.91.1.1) On 31 Jan 2024, at 10:15, Wojciech Puchar 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=