Here I am going to try to rewrite all my previous critics (positive and negative) related to CHERI architecture for software execution hardening and a better memory protection mechanism.
I have translated the PDF about cheri in french to facilitate my understanding of the original PDF in english.
The new critics I would formulate, beside those I have already mentioned are :
CHERI doesn't work for the stack, which is a major issue as hacks and attacks can still come from stack overflow and its exploitation by ROP/JOP.
Access to DDC (Default Data Capability) register, setting the rights for "non capability aware" instructions (normal code of the microprocessor) can cause issues for the exact same reasons as for PMMU configuration registers if a piece of code accesses them, they can disable all memory protection in a snap. Monotonicity is not enough, as a proven property, to sufficiently handle safely memory protection, according to me. Memory protection management, weither it is a PMMU or CHERI Capabilities should never be handled by mixed software and hardware, but completely by hardware : The underlying idea here is to prevent any software code hack to alter configurations.
CHERI Capability addresses (128+1 bits) fields should not be directly accessible to software, it should be hidden, and managed in a truly separate memory designed just for that and managed by the hardware implementation of CHERI exclusively. The user, from a software point of view, shall not be able to see internal fields, for obvious security reasons : The less can be seen from the software on how the memory is organized and managed, the better. Here I am really talking about design strategy and choices.
CHERI capabilities derivation process is still a fully hierarchic paradigm. At reset time of the processor, maximum rights are allowed to the first piece of code running, and then it keeps decreasing. This hierarchic approach, around software piece of code handling CHERI capabilities creation and derivation is not a good idea, because if a piece of code with an important zone granted is compromised or contains exploits or security breaches, everything that depend on it, all the subcapacities it generates, can be compromised too. I think, but we can discuss about it, that we cannot truly talk of security by compartmentalization of software / processes, as long as this whole thing is tied to a hierarchic tree of rights. CHERI hierarchic monotonic security model is not a good one. It's the same critic as for PMMU, except with PMMU there are only 3 level in the hierarchy : Hypervisor, privileged, user processor modes, with only the first two ones able to edit PMMU registers and configuration. If those two first are one way or another compromized, the whole security model crashes.
CHERI is still based on the current memoryspace concept, it's a new layer added onto it : This is due to the fact that they wanted to keep sufficient compatiblity with the processors they implemented CHERI on : All the problems dealing with side channels on the external microprocessor bus itself find no solution here : The typical example are those peripheral connected to the microprocessor bus that are NOT selected by the targeted address (And that therefore should NOT read or write any data on the bus, because the chip is not selected by the current address being set on the address bus) can cheat and still "listen" or even "write" (Creating a bus contention, but it this is intentional you know) :
The current microprocessor bus architecture concept takes for granted that ANY peripheral connected to the bus is "honnest" and will not "listen" or "write" if the addresses don't correspond to his addresses, but in the real world, nobody is honnest, and backdoors in many peripheral can be implemented to still listen to all transfers on the bus, even if their "chip select pin" is not activated. This is a major design security breach : We can't trust any peripheral, and currently they consider they are all honest and trustable.
