On Sat, Nov 11, 2023 at 08:14:46PM +0100, Bruno Haible wrote: > I was impressed by the fact that CHERI detected the multithread-safety > bug of gnulib's use of rand() in the test suite. > > Now I'd like to try CHERI on packages like gettext, and see whether > it finds bugs that neither valgrind nor the gcc bounds-checking options > can detect. > > For this purpose, it is useful if all functions that allocate memory > blocks return bounds for these memory blocks that are as tight as possible. > malloc(), realloc(), reallocarray(), alloca() already do so. > (To convince yourself, use a C program that makes use of these functions, > and print the return values from within gdb. gdb prints pointers with bounds.) > > This set of patches handles most memory allocators that we have in gnulib. > > The API is documented in > <https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf>.
Hi Bruno (and Paul, who I see has also posted some CHERI patches), I can see in your patches that you're using __CHERI__ as your ABI detection macro. Unfortunately, this currently isn't quite right. CHERI has two different ways you can compile for it: the first is the purecap ABI, what people normally mean when they say CHERI, where every pointer is a capability, but we also have a hybrid ABI, which is binary-compatible with non-CHERI code, treating all pointers as traditional integer addresses, but with the ability to qualify them with __capability to opt into them being capabilities (and (u)intcap_t for the (u)intptr_t case). Hybrid isn't particularly useful from a security perspective, it just exists to allow existing non-CHERI code to interface with CHERI code, but even then it's quite awkward to use, so our recommendation is to avoid it whenever possible. Unfortunately, the __CHERI__ macro is for detecting this latter case, i.e. just that you have CHERI ISA features available (cc -march=morello -mabi=aapcs for Morello), and so much of this code will now fall over in that environment (which is in fact the environment that CheriBSD's lib64 uses so as to enable the use of hybrid code). We don't do a good job of documenting this (AFAIR we don't document the macros at all in the above tech report), and ideally __CHERI__ would be the thing that most people want / expect it to be (one day we likely will make that change), but for historical reasons it's not. What you instead want is the (rather cumbersome) __CHERI_PURE_CAPABILITY__ macro, which is specifically testing for the pure-capability ABI, so hybrid code where pointers are plain integer addresses continues to use the old code paths rather than the new capability ones. Jess
