Johnathan, Thanks for this very detailed writeup! My general take is that this is probably the right direction for the next version of the ABI. A few high level comments, partially based on one-on-one discussion with you: First, good to separate the high level approach from the specific details of each system call. High level, this is basically defining a set of possible types that can be passed across the ABI, how those types are laid out in registers/memory when passed in various configurations and orders, and a way of communicating those which types are being passed. To that extent, one question is whether this covers all the right types and not more. My intuition is yes, it includes all of the typical primitive types we care about. It also includes "CHERI" capabilities as a "special" type, which is problematic on non-CHERI platforms, but I think this is easily captured by some general name like "descriptors" or something, that fit in a register, and refer to structure the kernel keeps track of (e.g. file descriptors---these are not meant to be CHERI pointers). Second, it's not totally obvious we need or want this first register that communicates the types across the ABI. In particular, for each call and response there _has_ to be a specific contract between the driver and process, as neither will deal with _all_ possible variants reasonable. We need a way to "communicate" or check that contract, but probably doing so at load time or installation time is better than dynamically. E.g., perhaps a TBF header that describes the expected interface from drivers and a loader (either on the host, at compile/composition-time, or in the kernel at dynamic installation time) ensures the kernel current drivers actually expose that interface. Conversely, what, if any, are the cases for dynamically checking the type of the arguments/returns across the ABI boundary? (this is a question for everyone, not just Johnathan) -Amit Johnathan Van Why via Devel <devel@lists.tockos.org> writes:
Inspired by the ongoing discussions about porting Tock to CHERI, I wrote down some ideas on how to make Tock's syscall ABI more type-safe. The writeup is in the design-explorations repository at Add an exploration of type-safe system calls <https://github.com/tock/design-explorations/pull/4>. While I'm not suggesting that we should start on Tock 3.0 now, I do think we should incorporate some of the design ideas into Tock 3.0 when it happens. A secondary goal of the document is to spread knowledge about CHERI.
Feel free to take a look, and either reply with feedback here or comment on the PR.
-Johnathan _______________________________________________ Devel mailing list -- devel@lists.tockos.org To unsubscribe send an email to devel-leave@lists.tockos.org