From nobody Wed Jul 31 15:46:27 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 4WYxKW5rbCz5S6Kc for ; Wed, 31 Jul 2024 15:46:39 +0000 (UTC) (envelope-from theraven@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 4WYxKW4zzYz40QL; Wed, 31 Jul 2024 15:46:39 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1722440799; 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=PfpzM2k237HHnjXJDVKcAula2Nck2bewkpHICsHiegM=; b=G831ol982h6DcGQowlMVAzOyU/rIJ7dYc+Gnx4ybhTaLMlinVL1K3fgsER8eoONvkg7nSP fVUp/R9UjOO+aM2up9wmw2wVUrPjl8dJb7j51SdtSfQIfk+o606AFiCbY5epbOicrJ+Ps0 LQXPmjuiuwCDZIuCU/tHg2r31jNdkj3gw74tJG9xCNc3QEKkbf/efT6pzo0ZHVa9PsYibU VC1y1V3SJPO8Bz6DltgnT1cjIIPPjPltfrN8A9wI/pHxIJFyWwnt0R4aqwdgW4HvYXv5Fs khctq0FLBUxmniEIrfgNLQ4LNe6dfHBWRcPlCVmOh7vYw44GGZyUzooPWaI6dw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1722440799; a=rsa-sha256; cv=none; b=r3zPIP/mWEa+pGgyHFqttPYcHt7wnUZRXCXO6zOrB2oFAGI9opC2ZJxshx6HzwRl4jaJpq CcAiIkxzOfZ7Dp/AE+D4RgXZyCw63RM4detwWrTbG3qXE02GKbBUMvM+nzKy+llTR87w2G d2OVKYD9O6jr8QTys2CwiRheIl5UupyQsV0FzNLR4aGlEq97yN2oHT10l5ySsGotpVdVLW LSKImNBkfF1e5A+NNd63QlBZT69VTZnAio8xtqXsNfXO6Ta6kIkOuGEz9QzeOtPePGbyKs GPpt2z2nD1yXn8QhGq5LsX1ZbOBJ86nY9kOt1cg33riIDAQbJR1ry6bxoSN5sQ== 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=1722440799; 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=PfpzM2k237HHnjXJDVKcAula2Nck2bewkpHICsHiegM=; b=F95wO0GUEbUUUBAo7ucI9covd6UUWiWmsVvQpY3KfadRuibGEIEWS52cBiStXpa4uO8zIR kG6NzoIXPOnhHxXBbdeIli0BR4CmHtNhiqe0wsN4Yd/C9gZUH9G7EBV/Zcwk9MnVuGnjpS tzO/exFmklB47c+CwLj/3pb4zErO+Rq3oimaG07OSpZrwcoSdi12oAiT+gyc4q2y3UYn7u +2hCAzjqTAwLSS66g9vnLe177J8LEH6DUmVegugFZTuOnQ+4C39aRA1PgHTUzg4R72rcsp +85qlNdnYdDBHFUD0ehWtwmHU3ifPxEBwdrhC0SDxZ9V1Of4GmoHB8pUJl/MVw== 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 4WYxKW4Qszz1CDV; Wed, 31 Jul 2024 15:46:39 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host86-138-165-11.range86-138.btcentralplus.com [86.138.165.11]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 65F804737; Wed, 31 Jul 2024 16:46:38 +0100 (BST) From: David Chisnall Message-Id: <1D235928-2513-45C1-8439-C2A2B9C58E46@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_80CE49DB-FD58-4421-9220-3682165573DE" 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.600.62\)) Subject: Re: The Case for Rust (in the base system) Date: Wed, 31 Jul 2024 16:46:27 +0100 In-Reply-To: Cc: Shawn Webb , FreeBSD Hackers , Warner Losh , Scott Long , meka@tilda.center To: Alan Somers References: X-Mailer: Apple Mail (2.3774.600.62) --Apple-Mail=_80CE49DB-FD58-4421-9220-3682165573DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 31 Jul 2024, at 16:40, Alan Somers wrote: >=20 > * ctld: while working on some bugs in ctld, I had trouble > understanding the config file parsing. So I rewrote that part in > Rust, just to help my understanding. Later, I rewrote the XML > parsing, too. Then I rewrote the LUN creation and deletion, just to > see how hard it would be. All of those parts take about 5x fewer SLOC > in Rust than in C, and they're less buggy, too. Config file parsing > is more consistent, no memory leaks, etc. Alas, I'm not planning to > finish this project, since the base system doesn't allow Rust and ctld > is too tightly coupled to ctl to live in ports. C is absolutely terrible for parsing on any metric (even C++ lets you = write parsers in a fraction of the code and fewer bugs). It=E2=80=99s = one of the places where Rust provides some very easy wins: - Lifetimes are easy to reason about in parsers, they fit well into = Rust=E2=80=99s ownership model because the input is a stream and the = output is a tree. - Parsers, by definition, are part of your attack surface because = they=E2=80=99re taking data from outside. Replacing parsers with Rust (or something like EverParse) has a very = high security return relative to the investment of effort. David --Apple-Mail=_80CE49DB-FD58-4421-9220-3682165573DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 31 Jul = 2024, at 16:40, Alan Somers <asomers@FreeBSD.org> = wrote:

* ctld: while working on = some bugs in ctld, I had trouble
understanding the config file parsing.  So I rewrote = that part in
Rust, = just to help my understanding.  Later, I rewrote the XML
parsing, too.  Then I rewrote the LUN creation and = deletion, just to
see how = hard it would be.  All of those parts take about 5x fewer = SLOC
in Rust = than in C, and they're less buggy, too.  Config file = parsing
is more = consistent, no memory leaks, etc.  Alas, I'm not planning = to
finish = this project, since the base system doesn't allow Rust and = ctld
is too = tightly coupled to ctl to live in ports.

C is absolutely terrible for = parsing on any metric (even C++ lets you write parsers in a fraction of = the code and fewer bugs).  It=E2=80=99s one of the places where = Rust provides some very easy wins:

 - = Lifetimes are easy to reason about in parsers, they fit well into = Rust=E2=80=99s ownership model because the input is a stream and the = output is a tree.
 - Parsers, by definition, are part of = your attack surface because they=E2=80=99re taking data from = outside.

Replacing parsers with Rust (or = something like EverParse) has a very high security return relative to = the investment of = effort.

David

= --Apple-Mail=_80CE49DB-FD58-4421-9220-3682165573DE--