Bounded pointers to stack allocated objects

[jwnrt]

Hi, I'm aware that the CHERIoT RTOS allocator will over-align and pad large heap allocations so that approximate bounds do not bleed out into other objects. Is the same true of stack allocated objects?

Specifically, if I have the following on my stack, can a pointer to a be used to access b?

void do_something(uint8_t *a);

void main() {
    uint8_t a[513] = {0};
    uint8_t b = 0;

    do_something(a);
}

I guess the same question applies to fields of structs: if I allocate an object with some large fields (on the heap or the stack), can a pointer to one of its fields bleed into another?

Does the compiler pad these things, or is the code responsible for doing the padding?

Many thanks

[davidchisnall]

Specifically, if I have the following on my stack, can a pointer to a be used to access b?

The compiler should insert enough padding for this. If you find a case where it is not, please file a bug.

I guess the same question applies to fields of structs: if I allocate an object with some large fields (on the heap or the stack), can a pointer to one of its fields bleed into another?

By default we do not enable sub-object bounds (and there's a compiler bug preventing them from being enabled (I'm not sure we're tracking this @rmn30 / @resistor?), which should be fixed soon). Without sub-object bounds, a pointer to a field has the bounds of the enclosing object.

With sub-object bounds, the compiler uses the imprecise version of the the set-bounds instruction. This means that a very large structure-field pointer would include access to one after (or possibly before if the start is also insufficiently aligned). Ideally the compiler would warn in these cases (it doesn't currently, I believe).

[jwnrt]

Thank you, that's very helpful. I couldn't find much in the CHERI C/C++ programmer's guide, just this sentence.

CHERI C/C++ have stronger alignment requirements than C/C++ on conventional architectures. [...] capability compression constrains the addresses that can be used for bounds on larger objects.

If there is a move to standardise CHERI C, I personally hope it's required that anything whose address can be taken with the & operator be over-aligned and padded, including field structs.

I wonder if that would make porting difficult for any existing code. I understand why sub-object bounds are disabled by default, but wonder if adding the padding unconditionally (when not packed) would be okay.