Support systems with 128-bit pointers.#19
Conversation
In order to allow meaningful comparisons between 32- and 64-bit systems, core_list_init hardcodes the size of pointers to be 8 bytes. This controls the number list elements allocated for a buffer of a given size. On a system with 128-bit pointers this results in data corruption as the list data is written over list_head objects. Address this by adding a POINTER_SPACE define which can be changed to 16. Update the checksums in the known_crc arrays for the run1.log and run2.log cases.
|
I don't necessarily expect this to be merged as is, but I'd like to start a discussion about how to support systems with 128-bit pointers. Our processors (http://chericpu.org) have 128-bit pointers. We have a variant for MIPS, we're working on one for RISC-V, and we've been working with Arm (who will be producing the Morello prototype architecture over the next couple years https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html). |
|
Hi there,
Update: Answering my own question. Pointer size is still 128-bit in 32-bit systems with Cheri. Note: Instead of defining POINTER_SPACE, maybe __SIZEOF_POINTER__ could be used instead. regards, |
CHERI Pointers on 32-bit systems are generally 64-bit. |
|
Ah, thanks @brooksdavis |
|
|
In order to allow meaningful comparisons between 32- and 64-bit systems,
core_list_init hardcodes the size of pointers to be 8 bytes. This
controls the number list elements allocated for a buffer of a given
size. On a system with 128-bit pointers this results in data corruption
as the list data is written over list_head objects.
Address this by adding a POINTER_SPACE define which can be changed to
16. Update the checksums in the known_crc arrays for the run1.log and
run2.log cases.