From nobody Fri Sep 6 21:46:00 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 4X0qY53zD5z5W3xQ for ; Fri, 06 Sep 2024 21:46:01 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0qY51NwGz4BGB; Fri, 6 Sep 2024 21:46:01 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725659161; 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: in-reply-to:in-reply-to:references:references; bh=MRMhe9nzuHXBqsPJ0khEyMDZr9dF4Md8il/sZSmnV2E=; b=pDXnwSdEuYiDKo9ygaPCVnMNT0/x1KY3WtnBRMHht3RTUWuAjLIp8Q9nJBlc1O85wWu+Yv cn7dzdO99ErKBULiM4ANHmNx4MArQdim5nbQsw7UuQIP0RIXpfHd3dl565WhFCVp/ghZqV bgq4djPtj7OIkKnXQvjcJ7FJfxQss2cl7+5oWLmIHL0Km6mrSibsZO1ISIHh4J6pONnf3O tP6G+L8PqqytswtKow2ab23eYeyI5t4pTizcxuIVbeLsA4nhBDkTy8EYzFusmkTD2xno4A tCSSr/tF+fc+J+h4nBZ+d8e8wTqhK7k6dU3pwfKnMQ2C+6U2irRmV3pz1E+Uuw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725659161; a=rsa-sha256; cv=none; b=mllY0FsqP3iY/QuYHogjhCKA1Ota58r2ZXdZtteWKvHRxu+Muj1exx3wYVDAajNob0n7qn VFe6Dknfq8kVUlpdWVv73V9nCg8JVwaQXn3ax7dh801+KjwG54vNELC7SdSz/xg4dCPbWW aX+FmH9JiNOewD7w+IujDE6dDnYWIOruS0v5Aj1/8k79/vhuGlcZ71MvIei1piPPEcI1zv wIhXagobR1MHTcX/xaLsD8V54Yj0HR68hKMaKF2DY9MKLFjrOMjMLvXW8E407xkVCmuz4l wequ7B+b6saGvIRCAnq3AdvQOjA8ns55zAbya+OdczXsUgfxhkKXh3s97xwxEQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725659161; 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: in-reply-to:in-reply-to:references:references; bh=MRMhe9nzuHXBqsPJ0khEyMDZr9dF4Md8il/sZSmnV2E=; b=Vhhayhrv1Q8WrKQcxhonNBThp2WXoSy/698zoQtAiSGQPBdjtfrYDh2/3mMf4wMEV4BpF9 mtUY5wgv9ZB8wQ369xnxjn71BLr1iLpzJOXheo+QwzxOX75q7QDeprZVABwq7qpj/pIpz3 Bl7FW3f4sp0P7q1dcwervzEjiA/qGh3RHgi/SRDLdyNxT08ygEOKqyCqDKsFqEokXfc0IB u8H2JwRGbJjDIfaRQsokeX/2LLP2OyB5qsM60f69n3j/LPDjE0ze8YlQLL9L9ZCvnVsoMj pyUFYvUMd41+ZxZGkpvLeHtTb5jYQf6Nn1dYO5W0PpQS7ahGnzchB0tT0Wb8sQ== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X0qY50l6TzbDn; Fri, 6 Sep 2024 21:46:01 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 682E23C019B; Fri, 06 Sep 2024 21:46:00 +0000 (UTC) Date: Fri, 6 Sep 2024 21:46:00 +0000 From: Brooks Davis To: Alan Somers Cc: FreeBSD Hackers Subject: Re: The Case for Rust (in any system) Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Sep 05, 2024 at 12:09:18PM -0600, Alan Somers wrote: > By now I expect that most of you have seen the long list of new > security advisories that just came out. Strikingly, all were the > result of memory handling errors. And none of them wouldn't have > happened if their respective programs had been written in a > memory-safe language. > > In fact, of all the C bug fixes that I've been involved with (as > either author or reviewer) since May, about three quarters could've > been avoided just by using a better language. > > The real takeaway here is that C is no longer sufficient for writing > high quality code in the 2020s. Everyone needs to adapt their tools. > Programmers who don't will increasingly come to resemble experimental > archaeologists, i.e. people who learn flintknapping to "keep the > knowledge alive". Such people are valuable, but definitely niche. I > for one don't want my career to go in that trajectory. I broadly agree and think that as a project we need to be willing to take some risks to move our development towards more modern solutions. Part of that likely means bringing kernel and userspace componants built in Rust[0] knowing there will be some integration bumps along the way and understanding that Rust may or may not stand the test of time to the degree C has (meaning burden or feature loss down the road). We need to move forward and all paths involve some risk[1]. While bugs you can't write because the language doesn't let you are the best bugs, we should also be looking at deterministic ways to improve our C and C++ memory safety. In my biased opinion, our most realistic option for making major advances here is the adoption of CHERI[2]. We've got Arm's Morello prototype today and we expect commercially available RISC-V silicon in the next year or so. At this point I hope to merge CHERI support from CheriBSD[3] in time for FreeBSD 16 (subject to standardization timelines, funding, and hardware availability). In the meantime, we should be looking at orthoginal techniques such as enabling default initialization of stack allocations. While the current state of affairs is quite problematic, we do have time. Regulators are aware of product lifetimes and realistic timeframes. We can afford to be methodical and not chase every trend, but I don't think we can afford to stand still. -- Brooks [0] Other languages might well make some sense, but I'd argue that we should not generally be adding languages that don't have clearly growing developer communities so some languages mentioned elsewhere are obvious nonstarters. [1] This includes the choice to continue as is. In particular, regulatory risk is hard to predict. [2] https://cheri-cpu.org [3] https://www.cheribsd.org