October 2024 - Devel - lists.tockos.org

Re: Tock meeting agenda 2024-10-04

by Amit Levy

FYI I am under the weather today but hopefully someone else will moderate.

Oct. 4, 2024

Tock meeting agenda 2024-10-04

by Amit Levy

Meeting Link: https://meetings.dialpad.com/room/tock/1vnk9r3e1b Agenda - Updates - Pointer returns from syscalls on non-32-bit platforms (https://lists.tockos.org/hyperkitty/list/devel@lists.tockos.org/thread/ACZB…)

Oct. 4, 2024

Call for Tock meeting agenda items 2024-10-04

by Amit Levy

Please response with proposed agenda items and +1s for tomorrows core meeting

Oct. 3, 2024

Re: Discussion on u32

by Amit Levy

> The current set of return codes include a type. e.g. calls like allow/brk currently return SyscallReturnU32U32 or SyscallReturnU32. Clearly this is not true for 64-bit platforms. Or for CHERI where the size of an address is not the size of a pointer. Excellent point, and this is definitely something to address. Thanks for noticing and bringing this up. I think given this is in the context of switching from only 32 support to adding 64 bit and/or CHERI, I don't think we should be overly concerned about breaking backwards compatibility. Instead, this is potentially a fine reason to think towards a 3.0 system call interface---one which shouldn't be overly difficult to port to, but wouldn't be binary compatible with applications compiled for 2.0. (we may lump in fully relocatable binaries and/or first-class non-XIP support if changing some expectations about binaries helps us accomplish that, as as potentially changes to core system interfaces, such as IPC) From that perspective, I think (1) is untenable. I think we should be much more concerned with portability of, e.g., capsules and a unified system call interface than with backwards compatibility. I don't think there is any advantage to (1) other than backwards compatibility. I think (2) is the answer. It follows the general idea in the MetaPtr PR (#4174) of converting naming things what they actually are. (3) I understand the expediency for a downstream port, but I don't see an advantage to this if we can do 2 (which I think we can). (4) Similar to 3. I think it would be _reasonable_, if we went with 3, to bump the major version number and redefine "success" to have the current value of successu32, such that it just happened to be the case that 2.0 binaries also turned out to work unmodified. -Amit

Oct. 3, 2024

Re: Discussion on u32

by Brad Campbell

At least some of the complexity results from system call arguments/return values which are sometimes arbitrary bit-limited values, and sometimes pointers. For example, memop 6 returns a pointer, whereas memop 7 returns a quantity. In contrast, allow only has pointers as arguments and returns pointers. One idea to consider is restructuring the system call interface to remove this ambiguity; arguments per system call are either pointers or values, but never both. - Brad On Wed, Oct 2, 2024 at 5:53 PM Lawrence Esswood via Devel < devel(a)lists.tockos.org> wrote: > I think this is a good discussion for Friday, but I wanted to send out an > advance email to give time for people to gather their thoughts in advance > > The current set of return codes include a type. e.g. calls like allow/brk > currently return SyscallReturnU32U32 or SyscallReturnU32. Clearly this is > not true for 64-bit platforms. Or for CHERI where the size of an address is > not the size of a pointer.I think there are a few options: > > 1. 1) They should return different codes on different platforms: > SyscallReturnu32 on 32-bit, SyscallReturnu64on 64-bit, > SyscallReturnMetaPtr on CHERI etc with some meta constructors to help > choose. Userspace should expect the same and be If-Defed appropriately. > 2. 2) They should return a new more specific code SyscallReturnPtr / > SyscallReturnUsize on all platforms, and user space should check for > just that one.e > 3. 3) These calls are already made type safe because of the wrappers > in libtock-c / libtock-rs. Just use SyscallSuccess for these built in > syscalls. Wrappers know what they are getting. > 4. 4) A true evil one. Option 3, but SyscallReturnu32 is the code for > legacy reasons. You know what you are actually getting. > > What I actually did on my fork was just 3 (because all these different > codes were getting in the way), but this does break compatibility unless > there is a matching change in libtock-c/libtock-rs and it would probably be > better not to do so. In fact, both 2 and 3 are breaking API changes. This > means that possibly we should prefer (1), simply for backwards > compatibility? This is roughly what the consttructor I added for > SyscallReturnUsize does: selects one of SyscallReturnu32 or > SyscallReturnu64 as appropriate. But possibly we will need a few more as > soon as CHERI comes into play.As for types for commands:Currently in the > kernel commands are:fn command(&self, cmd_num: usize, arg1: usize, arg2: > usize, appid: ProcessId) > Which is already usize-ified.In libtock-c: syscall_return_t > command(uint32_t driver, uint32_t command, size_t arg1, size_t arg2); > There is clearly a mismatch there on command number. I am of the mind that > the driver/command being u32 is fine, and args should really be usize. For > instance, a command might realistically take an offset to a previously > allowed buffer. This is usize, not u32.Upcalls: in the kernel were all > u32, I changed most of the arguments usize apart from data/fn pointer which > are MetaPtr. i.e., the type in C should be:typedef void > (subscribe_upcall)(size_t, size_t, size_t, void*);where currently it istypedef > void (subscribe_upcall)(int, int, int, void*);And I think its worth some > discussion whether people are happy with this. It means nothing for 32-bit > libtock-c because the ABI for passing usize is the same as int on 32-bit > platforms. In libtock-rs I have the patches ready to go to define the > upcall trait on both u32 and usize so it won't break any code there. > > Lawrence > > _______________________________________________ > Devel mailing list -- devel(a)lists.tockos.org > To unsubscribe send an email to devel-leave(a)lists.tockos.org >

Oct. 3, 2024

Discussion on u32

by Lawrence Esswood

I think this is a good discussion for Friday, but I wanted to send out an advance email to give time for people to gather their thoughts in advance The current set of return codes include a type. e.g. calls like allow/brk currently return SyscallReturnU32U32 or SyscallReturnU32. Clearly this is not true for 64-bit platforms. Or for CHERI where the size of an address is not the size of a pointer.I think there are a few options: 1. 1) They should return different codes on different platforms: SyscallReturnu32 on 32-bit, SyscallReturnu64on 64-bit, SyscallReturnMetaPtr on CHERI etc with some meta constructors to help choose. Userspace should expect the same and be If-Defed appropriately. 2. 2) They should return a new more specific code SyscallReturnPtr / SyscallReturnUsize on all platforms, and user space should check for just that one.e 3. 3) These calls are already made type safe because of the wrappers in libtock-c / libtock-rs. Just use SyscallSuccess for these built in syscalls. Wrappers know what they are getting. 4. 4) A true evil one. Option 3, but SyscallReturnu32 is the code for legacy reasons. You know what you are actually getting. What I actually did on my fork was just 3 (because all these different codes were getting in the way), but this does break compatibility unless there is a matching change in libtock-c/libtock-rs and it would probably be better not to do so. In fact, both 2 and 3 are breaking API changes. This means that possibly we should prefer (1), simply for backwards compatibility? This is roughly what the consttructor I added for SyscallReturnUsize does: selects one of SyscallReturnu32 or SyscallReturnu64 as appropriate. But possibly we will need a few more as soon as CHERI comes into play.As for types for commands:Currently in the kernel commands are:fn command(&self, cmd_num: usize, arg1: usize, arg2: usize, appid: ProcessId) Which is already usize-ified.In libtock-c: syscall_return_t command(uint32_t driver, uint32_t command, size_t arg1, size_t arg2); There is clearly a mismatch there on command number. I am of the mind that the driver/command being u32 is fine, and args should really be usize. For instance, a command might realistically take an offset to a previously allowed buffer. This is usize, not u32.Upcalls: in the kernel were all u32, I changed most of the arguments usize apart from data/fn pointer which are MetaPtr. i.e., the type in C should be:typedef void (subscribe_upcall)(size_t, size_t, size_t, void*);where currently it istypedef void (subscribe_upcall)(int, int, int, void*);And I think its worth some discussion whether people are happy with this. It means nothing for 32-bit libtock-c because the ABI for passing usize is the same as int on 32-bit platforms. In libtock-rs I have the patches ready to go to define the upcall trait on both u32 and usize so it won't break any code there. Lawrence

Oct. 2, 2024