Notes as I read this about CHERI.

I see first a reference to Intel’s MPX (Meat in section 9.1 (pp 1159) of this.)

I read this paper a couple of times before I realized that what the paper describes is not a mechanism to limit the authority of a user mode program, but instead a mechanism to make range checking more efficient and more likely. This is in turn to make code less gullible as it examines data from untrusted outside sources. A machine language program has available to it cap register C0 which is for all the authority that the conventional kernel provides to the entire address space.

My inclination just now is that such efforts complement Keykos style systems so as to provide a sort of defense in depth. Keykos claims to solve these problems by limiting the penetrator to small rewards after each penetration. The combination would indeed be welcome.

The plan seems to be to recompile much or all of the code that runs in an address space with some C compiler that has been taught to use these commands. I am disappointed that they do not describe the process of getting such recompiled programs running again. They have changed the defacto semantics of C and not all C programs that use the defacto semantics are unsafe. Indeed garbage collectors are likely broken in their model.

I think compiler flaws are a lesser security worry when you trust the writer of the source code not to be malicious.

I also wonder if the same goals could be met by using a type safe language in much or all of the system code. I wonder too how much of legacy system code will survive MPX or CHERI discipline. Intel says they have runtime mods for their C compiler. I would like to see a version of lib.c compiled in the new mode. Ditto CHERI.

Perhaps some programs written in higher level languages are limited. It would have saved much confusion if this had been made clear at the outset.

memcpy is done with a register that can hold either data or a cap, preserving the distinction.

I understand now how malloc works but not free. Are the caps to the freed area found and annihilated? Did the benchmarks include this overhead? Were any pages swapped out during the benchmark? Were those cleaned of caps before swapping?

“Revocation can be accomplished via zero-address-space-reuse allocators” What is a “zero-address-space-reuse”?

I am beginning to see these efforts as a means to put some teeth in the malloc-free mechanisms. This would truly be a big help.

Both of these systems seem to assume that the code is benign but buggy—gullible for short. In this case is it necessary to make the ‘capabilities’ opaque? This is not obvious.