Date: Fri, 6 Sep 2024 12:16:12 +0400 From: Antranig Vartanian <antranigv@freebsd.am> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: The Case for Rust (in any system) Message-ID: <A81EFC70-CA81-4773-9666-419D5871D335@freebsd.am> In-Reply-To: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_D5B2CD0A-492B-452B-98EB-B5B2BDD600BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alan, I agree, indeed, that we need better languages in the FreeBSD system. C = has=20 done its job very well in the last 50 years, and I think it will still = be=20 useful in the next 50. We can=E2=80=99t just =E2=80=9Crewrite=E2=80=9D = everything, but we can rewrite the=20 critical stuff. My question, however, is =E2=80=9CWhy Rust?=E2=80=9D. Rust is not the = only memory-safe language=20 out there. There are far better options for an Operating System like = FreeBSD,=20 where the language itself is way more stable and has less =E2=80=9Cmoving = parts=E2=80=9D. One of those options is a programming language that=E2=80=99s even older = than C by a=20 year. It=E2=80=99s Pascal. Yes, Pascal has a large ecosystem, but the = compiler itself is=20 small, and the language is stable. And the FreePascal community treats FreeBSD as a first class citizen. I,=20= however, have seen many issues with the Rust ecosystem when working on = FreeBSD.=20 I=E2=80=99m sure these issues will be fixed in the future, but for now, = the community=20 thinks that there are only three Operating Systems on the planet. And that=E2=80=99s just one option. Another one is Modula-2/Modula-3. It = was part of=20 FreeBSD two decades ago, and it is still a very stable and a robust = language.=20 There is even development happening to modernize their toolchain, but I = don=E2=80=99t=20 think that we need that. We can indeed use it =E2=80=9Cas is=E2=80=9D. Finally, there=E2=80=99s the last child of Niklaus Wirth, the Oberon = programming=20 language, which solves 99% of all C problems. There=E2=80=99s a compiler named =E2=80=9CVishap Oberon Compiler / = voc=E2=80=9D. I made sure that FreeBSD=20 is a first class citizen there about 8 years ago and we=E2=80=99ve been = using it on=20 production for 5 years now. One issue with Oberon (and its marketing) is that it relies on a = =E2=80=9CGarbage=20 Collector=E2=80=9D, which is not that nice for a low-level system = programming language.=20 However, I learned lately that the GC can be fine-tuned to make it = hardcoded=20 during compile time instead of runtime. My team is also willing to write a PoC of simple FreeBSD programs in = Oberon as=20 a proof that it works. I already have a PoC of a kernel module in Oberon = that=20 compiles on FreeBSD using voc. My point is: yes, we do need better languages. Yes, we do need = memory-safety=20 and better tooling. But is Rust the answer? Don=E2=80=99t want to sound like =E2=80=9Cbragging=E2=80=9D but the Rust = ecosystem is very new=20 while us, Wirthians, have been doing memory-safe programming since=20 the 80s. My personal problem with Rust is that the compiler is unstable (new = keywords,=20 deprecated keywords, but this can be solved, like you said, with version=20= pinning) and that, oh my god, the language is now massive. I like C = because I=20 *don=E2=80=99t* like C++, because I don=E2=80=99t want to learn for 2 = years before using on=20 Production. With Pascal, Modula and Oberon, I can just read a single = paper, and=20 start using the language. I=E2=80=99m sure there are other options as well. such as Ada. I=E2=80=99m= sure there=E2=80=99s more. If we=E2=80=99re gonna do the work to import a new language into FreeBSD = to solve C=E2=80=99s=20 problems, let=E2=80=99s have a look at all the options, not just the = ones that have the=20 budget for marketing. If we chose something based on marketing, we = wouldn=E2=80=99t=20 choose FreeBSD in the first place, am I right? ;) I hope this gives a better direction for the future. Kind regards, =E2=80=94 Antranig Vartanian https://antranigv.am/ PGP Key ID: 0x2D59F21C > On 5 Sep 2024, at 10:09=E2=80=AFPM, Alan Somers <asomers@freebsd.org> = wrote: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > To summarize, here's the list of this week's security advisories, and > also some other recent C bug fixes of my own involvement: >=20 > Buffer overflow > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D3aaaca1b51ad844ef9e9b3d945217ab3= dd189bae > CVE-2024-45288 FreeBSD-SA-24:09.libnv > = https://cgit.freebsd.org/src/commit/?id=3Da06fc21e770a482c8915411ebc98c870= e42dd29b > CVE-2024-41928 FreeBSD-SA-24:10.bhyve > = https://cgit.freebsd.org/src/commit/?id=3Daf438acbfde3d25dbdc82b2b3d72380f= 0191e9d9 > CVE-2024-42416 FreeBSD-SA-24:11.ctl > = https://cgit.freebsd.org/src/commit/?id=3Ddb87c98168b1605f067d283fa36a7103= 69c3849d > FreeBSD-SA-24:11.ctl > = https://cgit.freebsd.org/src/commit/?id=3D5c9308a4130858598c76f3ae6e3e3dfb= 41ccfe68 > CVE-2024-32668 FreeBSD-SA-24:12.bhyve >=20 > Integer overflow > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D36fa90dbde0060aacb5677d0b113ee16= 8e839071 > CVE-2024-45287 FreeBSD-SA-24:09.libnv > = https://cgit.freebsd.org/src/commit/?id=3Dc3e6dfe55c0e81d0717b0458bc951283= 84c3ebe8 > FreeBSD-SA-24:14.umtx >=20 > Use after free > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D670b582db6cb827a8760df942ed8af00= 20a0b4d0 > CVE-2024-45063 FreeBSD-SA-24:11.ctl > = https://cgit.freebsd.org/src/commit/?id=3D62f40433ab47ad4a9694a22a0313d576= 61502ca1 > CVE-2024-43102 FreeBSD-SA-24:14.umtx >=20 > Uninitialized memory access > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3Dea44766b78d639d3a89afd5302ec6fef= faade813 > CVE-2024-8178 FreeBSD-SA-24:11.ctl > = https://cgit.freebsd.org/src/commit/?id=3D0f2b2276abc305905e7d88619a7abca2= 6b0dd7eb >=20 > Memory Leaks > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D2909ddd17cb4d750852dc04128e584f9= 3f8c5058 >=20 > Incorrect union member access > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D9a5a7c90d5e5971fe2b9c9265e9279a6= f173a8f3 > CVE-2024-6119 FreeBSD-SA-24:13.openssl >=20 > Concurrent unsychronized memory access > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D1f5bf91a85e93afa17bc9c03fe7fade0= 852da046 >=20 > RAII > =3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D4b3141f5d5373989598f9447ab5a9f87= e2d1c9fb >=20 > Unchecked errors [^1] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D35f4984343229545881a324a00cdbb39= 80d675ce > = https://cgit.freebsd.org/src/commit/?id=3Deced2e2f1e56b54753702da52a88fccb= e73b3dcb > = https://cgit.freebsd.org/src/commit/?id=3Df625d038d2ae59fa1ae81b76079da464= ed6db61a >=20 > Not preventable by a safer programming language > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = https://cgit.freebsd.org/src/commit/?id=3D7d6932d20aedbbb220cd78e90ab4e82d= 1abaad31 > = https://cgit.freebsd.org/src/commit/?id=3D6efba04df3f8c77b9b12f1df3e5124a7= 249b82fc > = https://cgit.freebsd.org/src/commit/?id=3D4b72bab96e8978eaed30fd44f7f51e1b= 4918d4db > = https://cgit.freebsd.org/src/commit/?id=3Db64afa41d56e98b5817aaf14c7deb0fa= 7e2142fb >=20 > [^1]: while not memory-safety bugs, Rust's lints actually make > ignoring errors like this pretty difficult. So I consider these bugs > to have been preventable. >=20 --Apple-Mail=_D5B2CD0A-492B-452B-98EB-B5B2BDD600BC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElMZjj3yN+bx0tQ6G3jmYZi1Z8hwFAmbaukwACgkQ3jmYZi1Z 8hzvHQ/+PJAXXKuTCOQiOsBCAS8ztPyYsItjrKKh8/R/vpW0Cclzp8XekkS806JY ES5wrnLdTFLc6m0mN20N+GYsmTZ6WpDRiprTYBamlcta6hL764/OuM+ro5Z3fBD5 aldM6eTVaVRzLILmEaLCwP9dElJw1J0K41W3em0thcUQETmri/+1kDLfS+G/qp+/ zb97W2ykeaaSjsJt6gZ7EAOlzVDuND7HM+atJ6mgPjbsOZrB2PC9S0HnWA39qIBc BrQNcTd6X4Mz0D7QeHHQxgQuoDa+8ao+RzP0zbAaeg4FB1aYfzdGUIpQd8hjJNqJ Zt9+NQjwS5s+4pBv4MBVzUxnG+jBwijbR4mcxFfNTGP1oq6ZVhe2j4teRSyo0OsU flITgTxb5La4Xrj810wRiqo0jMt75rRhAT8EB4BCSoTRQkiaeuwX4WqomSQ5uTes L+aim2YAN6xLYb1f+WXsAnSqlCK5xx2RpconYPsXyqThNaL90I3MZ7dAWeF29akU xPg7jUKB2lS1ID2x4vxJA3d61u7fXi+P6CBs6gis4UqnMAUCHY6LhdcGc99y+Io4 vCAIlxZq8zOO0uxOuF+lrBr2szsNZMfM27ry8dAWhDk3vTx1gkbwro6C6XhyV8o+ tFU1qu/546xX//BHXGS0DrbLDJPfCJGque27jZKl1ajxyUWW1zk= =CBTL -----END PGP SIGNATURE----- --Apple-Mail=_D5B2CD0A-492B-452B-98EB-B5B2BDD600BC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A81EFC70-CA81-4773-9666-419D5871D335>