zlacker

[parent] [thread] 2 comments
1. jacque+(OP)[view] [source] 2022-01-20 17:06:40
I think this is an extremely important and timely development, I sincerely hope that you succeed and will be following the project closely from now on.

One more question: does the CHERI add on introduce new 'uLimit' like limitations, for instance the number of allocatable blocks or will it scale seamlessly with whatever the various memory management functions and system calls provide?

replies(1): >>jrtc27+d2
2. jrtc27+d2[view] [source] 2022-01-20 17:17:34
>>jacque+(OP)
The only thing that gets weird is the primary thread's stack limit, since we need to construct that capability up-front with the right bounds. This means we have a somewhat arbitrary upper limit (which you could make tunable, though I don't think we do, just a #define'd constant) that should be big enough for any reasonable process and reserve all that virtual address space regardless of what the stack limit is (but it's still unmapped and not backed by anything, just a big region of "don't use this as another capability already overlaps with it"). You can then use rlimit(2) to configure your stack limit and the virtual memory subsystem will do the same as it does on non-CHERI, just you won't be able to exceed that threshold, and the capability's bounds for the stack pointer will always cover the maximum possible mapping, not the mapping you're actually using.

Everything else is the same, just "as much as your system can fit (and system policies will let you)". Which will be slightly less, because pointers are bigger, but we don't have any additional tables that impose arbitrary restrictions on what you can do.

replies(1): >>jacque+n8
◧◩
3. jacque+n8[view] [source] [discussion] 2022-01-20 17:45:52
>>jrtc27+d2
Ok. Super cool that you have thought so far ahead in designing this. Looking forward to being able to use it in production!
[go to top]