From nobody Sun Sep 08 08:53:57 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 4X1kKY1Jmxz5WR05 for ; Sun, 08 Sep 2024 08:54: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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X1kKY0N9Nz4b8X; Sun, 8 Sep 2024 08:54:09 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725785649; 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=Fv0R2cEL6sbtA9niIe1mbaSWKe2aSZl2+u1graIFWac=; b=o9FPhC2ScV+hVidqD4BgnIEqWhqF6QAaKwLIgK1WQl0x9xuVciQdjALlFLhIovU+Qt+Yej ipyBcKeHdOpvfZTAPcHB/UqRrSfFF5yrvvF9upeB0T7biWyArupb8fcYbvFWH2NAMm6up6 pQ3tCH0HJz8BYdLOdPOXs931l+jNkTtwBJx+uvEUBtVGOchbRVqTTadDx+ZdFKlLKaeicB h6U0Su+CFNMKs9aUt5J67Ux90zGHpwn8RV0ibmrh5SGKCjixWh4VGwKd5kCcpqmiq2XdEm T5GPSgNTGL4XFqHi3LkzklHC5E5htBP/XDaHaVp/WtKXzoCpC9wi45vn4DxIqg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725785649; a=rsa-sha256; cv=none; b=ZxwgOEN52xIsO/kUbSCWtkE82YVYIud9Fz8alT07gIsZG1xsRtm5pB1K1Ffe6BdAB1HMkQ hG1D/2YIFhLZHI6oFomsnb79RD8pWwm3NlITNoVROf6RegN1NXQtvPVo/XnjGFv0Zbfizu yqIqh4KwnfZ18+4/AOoH6Yl8pVVouDtHzeRCn/+zLqvIpBJFy/ofo27sM68nacji/KCr8f sKJSfp+yYOGptm8sQ/qmUQjfBlY9uKi/rEMlqI8mDo/Q/im01JvOMTo9Kk24Dps63P23v7 fBfcJ9Fyp69C4JZfRJTjERYS5VWy2YgzBbhV1MKcytHcgRVFwSnqVPYsHnj7rw== 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=1725785649; 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=Fv0R2cEL6sbtA9niIe1mbaSWKe2aSZl2+u1graIFWac=; b=Tw6FYf45lz0mAErzWKNo8IoqVmOxfLGr9598fus3i1WLZ49lCBJ1QwS7/rWfbQwr5QiIw9 Aqb/UKAX6jFDsbt3amR//ONJK1ElBc+bI7Z3PTXLS9RQxYRHikjr5PuYbxhh8z0c1njhd9 jmVTqoKkbsTvn7gNQZOKDgOycnqONmOoxZQ1TgBuQtP5OfBviDc9xGgvrJAckIdPTQ8lkY a//dKRKYK0HVJZk8pRbF3a5+JNkrKdlqqwK5/5z8IPgqZ20O4y22tKA7DUX22So4l0PX4B gDzgWA1ufX7zhKi8wHlwjdhV/Tm/jTZN2xIKZvlHfb6qdCpsE9YcMqMy34FQvw== 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 4X1kKX6wnnzKQ6; Sun, 8 Sep 2024 08:54:08 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 7C0816558; Sun, 08 Sep 2024 09:54:08 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-A0EC2FF2-7F8A-4D21-A958-19E93388C397 Content-Transfer-Encoding: 7bit From: David Chisnall 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 (1.0) Subject: CHERIoT RTOS C++ [Re: The Case for Rust (in any system)] Date: Sun, 8 Sep 2024 09:53:57 +0100 Message-Id: References: <5d707cd5-ee31-4cce-98b7-3826e891a2dd@gmail.com> Cc: freebsd-hackers@freebsd.org In-Reply-To: <5d707cd5-ee31-4cce-98b7-3826e891a2dd@gmail.com> To: Paul Floyd X-Mailer: iPad Mail (21G93) --Apple-Mail-A0EC2FF2-7F8A-4D21-A958-19E93388C397 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Changing the title so people who don=E2=80=99t care can easily ignore this t= angent. > On 7 Sep 2024, at 20:20, Paul Floyd wrote: >=20 > Out of curiosity, did that mean limiting the ABI use (no RTTI or exception= s). Did it also allow using different compilers (say clang and GCC)? We=E2=80=99re targeting tiny embedded systems. The total code size for the c= ore RTOS (scheduler, memory allocator, switcher) is around 10 KiB, so except= ions are totally infeasible. A stack unwinded would be as big as the total a= mount of RAM on some of the SoCs we want to be able to support. We also don=E2= =80=99t use RTTI for a similar reason. We do have a tiny C++ runtime for laz= y static initialisation. I wish the C++ standard would lose its allergy to subsetting, because the st= andard not subsetting does not prevent it happening, it just means everyone d= oes it differently. In terms of library support, we claim to be a freestandi= ng implementation and also provide a bunch of things from hosted implementat= ions. A lot of the normal standard library types are not well suited to envi= ronments where memory allocation can fail and where exceptions don=E2=80=99t= work (the libc++ code calls abort in these cases, we want things that retur= n std::optional for things that might fail). We are co-designing the hardware and software. We have some FPGA prototyping= platforms (lowRISC has built a really nice one) and the company I cofounded= will ship commercial silicon next year. We have some extensions beyond CHER= I that enable deterministic heap temporal safety as well. As soon as you fre= e an object, all pointers to it become unusable (and then we have some addit= ional hardware that makes it possible to safely reuse the memory).=20 So it=E2=80=99s not quite normal C++. We can inspect a pointer and tell what= its bounds are, what its permissions are, and whether it=E2=80=99s valid. W= e can also transform it into a tamper-proof =E2=80=98sealed=E2=80=99 pointer= that can be unsealed only if you hold the relevant unsealing token. This ca= n protect things like socket handles: the TCP/IP stack hands out a sealed po= inter to the socket state and can check when you pass it back that it is the= correct type and can then unseal it, but you everything else that pointer i= s a value that can be copied around but can=E2=80=99t be used. We can do som= e fun things (it=E2=80=99s possible to represent all of the state of a std::= vector with a single pointer, for example) and, in some places, we skip stat= ic memory safety checks and instead write code that expects to fail and retu= rn to the calling compartment if it encounters a memory-safety bug. This set of primitives lets us build a rich compartmentalisation model where= communication between compartments looks like a function call and sharing m= emory is accomplished by passing pointers (which may have restricted permiss= ions, including shallow or deep immutability and no-capture guarantees). On t= op of this, we have built auditing tooling that lets you see which compartme= nts call which entry points in others, which compartments have access to whi= ch MMIO regions, and so on. Our ABI defines a bunch of things that are extensions to the Itanium ABI suc= h as calling conventions for cross-compartment calls, shared libraries (whic= h, for us, are stateless and don=E2=80=99t involve a security domain crossin= g, whereas compartments do). We don=E2=80=99t have support for more than one compiler at the moment becau= se our extensions are implemented only in clang. There is nothing stopping a= nyone adding the same support in other compilers though and I=E2=80=99d be h= appy to help anyone who wanted to do gcc bring up. More details (code, formal model of the ISA, programmers=E2=80=99 handbook, a= nd so on here): https://cheriot.org/ David --Apple-Mail-A0EC2FF2-7F8A-4D21-A958-19E93388C397 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Cha= nging the title so people who don=E2=80=99t care can easily ignore this tang= ent.

On 7 Sep 2024, at 20:20, Paul Floyd <paulf2718@gmail.com> wrote:
Out of c= uriosity, did that mean limiting the ABI use (no RTTI or exceptions). Did it= also allow using different compilers (say clang and GCC)?

We=E2=80=99re targeting tiny embedded systems. The total code size= for the core RTOS (scheduler, memory allocator, switcher) is around 10 KiB,= so exceptions are totally infeasible. A stack unwinded would be as big as t= he total amount of RAM on some of the SoCs we want to be able to support. We= also don=E2=80=99t use RTTI for a similar reason. We do have a tiny C++ run= time for lazy static initialisation.

I wish the C++= standard would lose its allergy to subsetting, because the standard not sub= setting does not prevent it happening, it just means everyone does it differ= ently. In terms of library support, we claim to be a freestanding implementa= tion and also provide a bunch of things from hosted implementations. A lot o= f the normal standard library types are not well suited to environments wher= e memory allocation can fail and where exceptions don=E2=80=99t work (the li= bc++ code calls abort in these cases, we want things that return std::option= al for things that might fail).

We are co-designing= the hardware and software. We have some FPGA prototyping platforms (lowRISC= has built a really nice one) and the company I cofounded will ship commerci= al silicon next year. We have some extensions beyond CHERI that enable deter= ministic heap temporal safety as well. As soon as you free an object, all po= inters to it become unusable (and then we have some additional hardware that= makes it possible to safely reuse the memory). 

So it=E2=80=99s not quite normal C++. We can inspect a pointer and tell w= hat its bounds are, what its permissions are, and whether it=E2=80=99s valid= . We can also transform it into a tamper-proof =E2=80=98sealed=E2=80=99 poin= ter that can be unsealed only if you hold the relevant unsealing token. This= can protect things like socket handles: the TCP/IP stack hands out a sealed= pointer to the socket state and can check when you pass it back that it is t= he correct type and can then unseal it, but you everything else that pointer= is a value that can be copied around but can=E2=80=99t be used. We can do s= ome fun things (it=E2=80=99s possible to represent all of the state of a std= ::vector with a single pointer, for example) and, in some places, we skip st= atic memory safety checks and instead write code that expects to fail and re= turn to the calling compartment if it encounters a memory-safety bug.<= div>
This set of primitives lets us build a rich compartmental= isation model where communication between compartments looks like a function= call and sharing memory is accomplished by passing pointers (which may have= restricted permissions, including shallow or deep immutability and no-captu= re guarantees). On top of this, we have built auditing tooling that lets you= see which compartments call which entry points in others, which compartment= s have access to which MMIO regions, and so on.

Our= ABI defines a bunch of things that are extensions to the Itanium ABI such a= s calling conventions for cross-compartment calls, shared libraries (which, f= or us, are stateless and don=E2=80=99t involve a security domain crossing, w= hereas compartments do).

We don=E2=80=99t have supp= ort for more than one compiler at the moment because our extensions are impl= emented only in clang. There is nothing stopping anyone adding the same supp= ort in other compilers though and I=E2=80=99d be happy to help anyone who wa= nted to do gcc bring up.

More details (code, formal= model of the ISA, programmers=E2=80=99 handbook, and so on here):

https://cheriot.org/

David

= --Apple-Mail-A0EC2FF2-7F8A-4D21-A958-19E93388C397--