Jessica Clarke wrote:
> So it’s not really a case of not being necessary, it’s a case of “are
> you using void * or using void * __capability everywhere to opt into
> capability use?”
Indeed, when I try to compile the current Gnulib code in "hybrid" mode
(CC="clang -march=morello"), I get
On 2023-11-12 20:15, Jessica Clarke wrote:
it’s a case of “are
you using void * or using void * __capability everywhere to opt into
capability use?” Unless that’s what you mean by necessary?
It seems pretty clear that Gnulib should run, run away from hybrid mode
as fast as it can.
On 2023-11-12 19:10, Bruno Haible wrote:
So, if I understood it correctly, in hybrid mode (2), programs (especially
memory allocators)_can_ use and its functions, but it's not
necessary since the programs will also work without it?
So __CHERI__ currently means "either hybrid or pure
On 13 Nov 2023, at 03:10, Bruno Haible wrote:
>
> Jessica Clarke wrote:
>> I can see in your patches that you're using __CHERI__ as your ABI
>> detection macro. Unfortunately, this currently isn't quite right.
>> ...
>> we also have a hybrid ABI, which is
>> binary-compatible with non-CHERI
Jessica Clarke wrote:
> I can see in your patches that you're using __CHERI__ as your ABI
> detection macro. Unfortunately, this currently isn't quite right.
> ...
> we also have a hybrid ABI, which is
> binary-compatible with non-CHERI code, treating all pointers as
> traditional integer
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
I wrote:
> 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.
Did that. Indeed, CHERI found a memory overrun bug that valgrind had not found
[1]. Just by running "make check" after configuring
> This set of patches handles most memory allocators that we have in gnulib.
And this patch handles the 'ssfmalloc' memory allocator.
2023-11-11 Bruno Haible
ssfmalloc: Take advantage of CHERI bounds-checking.
* lib/ssfmalloc.h: Include .
(struct
On 2023-11-11 13:23, Bruno Haible wrote:
Ah? Which documented functions should I be wary of?
Not sure. But for starters, vaddr_t is obsolete.
I was toying with the idea of not using cheri.h, and just using compiler
builtins. That may be going too far, though.
Paul Eggert wrote:
> I tried hard to add support with as few #ifdefs as possible, to avoid
> cluttering the code. Instead, I created a relatively small include file
> ptr-bounds.h that packaged things up into easy-to-use macros. This meant
> most of the rest of the Emacs code didn't need to use
.
> (mmalloca) [CHERI]: Return a pointer with a tight upper bound.
> (freea) [CHERI]: Update.
>
> 2023-11-11 Bruno Haible
>
> safe-alloc: Take advantage of CHERI bounds-checking.
> * lib/safe-alloc.h: Include .
> (safe_alloc_realloc_n): Wh
On 2023-11-11 11:14, 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.
I was also impressed in 2017 when Intel MPX found some pointer bugs in
Emacs, and I added support to Emacs for gcc
upper bound.
(freea) [CHERI]: Update.
2023-11-11 Bruno Haible
safe-alloc: Take advantage of CHERI bounds-checking.
* lib/safe-alloc.h: Include .
(safe_alloc_realloc_n): When count or size is 0, return a pointer whose
bounds are of size 0, not 1.
2023
13 matches
Mail list logo
