From nobody Tue Jan 23 09:30:04 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 4TK1yx5PNtz57g5B for ; Tue, 23 Jan 2024 09:30:17 +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 4TK1yx4v50z514W; Tue, 23 Jan 2024 09:30:17 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706002217; 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=SrDKaqpdhJD75VXj8QTgC74E9vukrqcF+DDU8QU0d+Y=; b=pGA/ND28TyIEsR7RKCerZTm9kjh9YdDIuZztEqCj7SdnWXhHBREEsKJ0yskcsLljzgNLKx jspbRK1BvtLrak6Gcth9h0Ntm3s9lGdBD8vEdc2AbygfnRgFTqYW6mnhHANL7kuNviAtu/ GAsL/a7/v1QxxWmwkCR6xKgwX5e0F1XH4hpiru3HLRYH+dSQBaSyHDBcJqEjbZPoR9p5BW roGAH4UBJ6gy88++717HqKx6E8nPXIsQqdhn6v/RaSNjfKmMH0ugCV841IhOdIJz0K8gsw +1OSRxvLzSy4IB5jVHWYv86eBZAC1BIn9gcT9xQz2imN2vL0muPBQx1SI5nqRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706002217; 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=SrDKaqpdhJD75VXj8QTgC74E9vukrqcF+DDU8QU0d+Y=; b=UiiKGo96XhtfuB0W5BY2zwbaYcdxbMV9h6I+pSeQPRVhobFZ07rE0iMJ7fGr021sDT0hWr t44OauBipANgZgGBE20vNTSZ7koGe93Ut8p+Y4omJftBq8jbetVeCDK4D6O/7zmURSRedM nfPXGflG4VMulogBde4G4ssJndHO0tYXuz6Fu0WnOXr3qGMl0qOwqbm/B95g3XKvAFBv/G qWpl2Nu+NMTaRmhyL3b4CvknPueRYA2z9ggg++M7FMgYtLAD+8PLBsdK1k3G2mSyLJoz7v AjMtdH0vRcf6txbvuNyILjMIVZRurONDH6t6tG+WQBsDyMTLeQ7FzdKqw+qJyA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706002217; a=rsa-sha256; cv=none; b=MqHQnaY1iKj1FOirwRSDOIPzs4eFjnPTUXn0WtPHqplGtA/IyKYGRbNDd5uXoRqQXiQ69k JjFPR7ix/DH6/PHbMS+8etRnCMABptkeILG6dc/eDgY8pJTadR5LCdFvL/isM1gwS1BDEo H00Ym4SAFAhhhEDaUqjgmva/UoTo4zoyKL/NcqXinT329wOOsR4PtQgxAhYQQEhE3iHozJ FAn1IVkQqxOPLHtrx50eFKvX+l3g9AVBbmF0/e6frfgzQjGGKtOYo9+Iel8SgZI0k+u5N3 T2A2eLvRpO5v6Q2gOyyyvEc8aKroDa9fuweDoyQbfhEBwfrYFj/iCTa4Mdu7mA== 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 4TK1yx3p5cz1FBG; Tue, 23 Jan 2024 09:30:17 +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 BF5BFBF48; Tue, 23 Jan 2024 09:30:16 +0000 (GMT) From: David Chisnall Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AC930FBE-94A8-464C-80EC-C737039B679B" 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) Date: Tue, 23 Jan 2024 09:30:04 +0000 In-Reply-To: <20240122165452.13733a66@venus.private.rrbrussell.com> Cc: freebsd-hackers@freebsd.org To: "Robert R. Russell" References: <1673801705774097@mail.yandex.ru> <202401210751.40L7pWEF011188@critter.freebsd.dk> <40bc1694-ee00-431b-866e-396e9d5c07a2@m5p.com> <20240122165452.13733a66@venus.private.rrbrussell.com> X-Mailer: Apple Mail (2.3774.200.91.1.1) --Apple-Mail=_AC930FBE-94A8-464C-80EC-C737039B679B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 22 Jan 2024, at 22:54, Robert R. Russell = wrote: >=20 > If you had to estimate what is the cost of enforcing better C++ code? For CHERIoT RTOS, we use clang-tidy to run the static analyser. It=E2=80=99= s the longest CI job, by quite a large margin, but it=E2=80=99s a small = enough project that we haven=E2=80=99t felt the need to trim what it = runs on, so we run it on *every* file on every commit to a PR. =20 It=E2=80=99s also something that you need to do from the start. If you = run the clang analyser or Coverity on FreeBSD, you get a vast number of = false positives and so having a =E2=80=99no warnings=E2=80=99 policy is = impossible to enforce. I would recommend doing it on a = per-compilation-unit basis: - New files must have no new warnings. - Old files get opted in once they=E2=80=99re clean and must then have = no new warnings. - Anything that explicitly silences a false positive needs sign-off = from two committers in code review. At the very least, the last point will likely get the comment ratio up a = bit, since the code will need to actually be readable by other people to = make it into the tree. Even then, there=E2=80=99s likely to be a bit of churn when you update = to newer versions of the analysers. Making this work really just needs build system infrastructure to = generate a compile_commands.json (something that any build system that = isn=E2=80=99t Make can do. I know MaskRay has written some scripts to = try to generate one from bmake but I couldn=E2=80=99t get them to work) = and some work from the CI team. They=E2=80=99re currently understaffed = and under-resourced. =20 > I am not familiar with Lua and most of my experience with Lua like > languages have included dynamic code injection as an attack vector. Is > it feasible to protect Lua from that problem in the use case you > propose? Yes. Don=E2=80=99t call `eval` on untrusted input. David --Apple-Mail=_AC930FBE-94A8-464C-80EC-C737039B679B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 22 Jan = 2024, at 22:54, Robert R. Russell <robert@rrbrussell.com> = wrote:

If you had to estimate what is the cost of = enforcing better C++ code?

For = CHERIoT RTOS, we use clang-tidy to run the static analyser.  It=E2=80= =99s the longest CI job, by quite a large margin, but it=E2=80=99s a = small enough project that we haven=E2=80=99t felt the need to trim what = it runs on, so we run it on *every* file on every commit to a PR. =  

It=E2=80=99s also something that you = need to do from the start.  If you run the clang analyser or = Coverity on FreeBSD, you get a vast number of false positives and so = having a =E2=80=99no warnings=E2=80=99 policy is impossible to enforce. =  I would recommend doing it on a per-compilation-unit = basis:

 - New files must have no new = warnings.
 - Old files get opted in once they=E2=80=99re = clean and must then have no new warnings.
 - Anything = that explicitly silences a false positive needs sign-off from two = committers in code review.

At the very least, = the last point will likely get the comment ratio up a bit, since the = code will need to actually be readable by other people to make it into = the tree.

Even then, there=E2=80=99s likely to = be a bit of churn when you update to newer versions of the = analysers.

Making this work really just needs = build system infrastructure to generate a compile_commands.json = (something that any build system that isn=E2=80=99t Make can do. I know = MaskRay has written some scripts to try to generate one from bmake but I = couldn=E2=80=99t get them to work) and some work from the CI team. =  They=E2=80=99re currently understaffed and under-resourced. =  

I am not familiar with = Lua and most of my experience with Lua like
languages have included dynamic code injection as an attack = vector. Is
it = feasible to protect Lua from that problem in the use case you
propose?

Yes. =  Don=E2=80=99t call `eval` on untrusted = input.

David

= --Apple-Mail=_AC930FBE-94A8-464C-80EC-C737039B679B--