"Tootsie Pop" model for unsafe code

One thing I'll note is that consume_from_usize() is not only undefined behavior according to C, but is actually disallowed by hardware that has been built. This is noted in http://www.cis.upenn.edu/~stevez/papers/KHM+15.pdf :

While the language definition provides an integer type uintptr_t that may be legally cast to and from pointer types, it does not require anything of the resulting values [5, 7.20.1.4p1].

C standard, 7.20.1.4p1:

The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:

intptr_t

It does not require the result be dereferenceable in any way - it's certainly permissible to set a flag bit that makes dereferencing it trap, or optimize away comparisons but turn dereferences into an unconditional error at compile time.

As for hardware, CHERI (A MIPS based on the BERI implementation) is a capability-enhanced ISA designed according to the rules of C, on which conversion of an integer to a pointer would result in a capability to memory of zero length - one which can be compared to other capabilities, but not dereferenced to any memory.

As a result, it seems to me that any unsafe boundary broader than the module would have the sole benefit of permitting behaviors that are very likely to be broken by lower levels of the compiler and high-security hardware anyway.

1 Like