Misleading/incorrect text surrounding temporal safety

[jrtc27]

In "Security analysis of CHERI ISA.pdf", the "Temporal safety" section says:

however there have been architectural extension proposals such as CHERIvoke and MarkUs which allow temporal safety enforcement built upon hardware capabilities

Firstly, CHERIvoke is just an algorithm that works on CHERI without any additional architectural extensions. Whilst the paper does propose both CLoadTags and CapDirty as extensions, they are both merely optimisations, with the former allowing capability-free cache lines to be skipped over more efficiently, and the latter removing the need to emulate CapDirty emulation in software (as is done with normal dirty tracking on architectures that only have a W bit with no corresponding D bit). Notably, the follow-up Cornocopia paper, which is to a first approximation just implementing CHERIvoke on CHERI-MIPS+CheriBSD, did not use hardware CapDirty tracking and just emulated it in software (but did make use of CLoadTags to help performance).

Secondly, MarkUs does not build upon hardware capabilities. It was written to be conservative like BDW is as a GC. Like BDW it can of course be made precise in the presence of CHERI due to no longer needing to guess whether an integer is a pointer or not, but the paper targeted a plain Intel Core i5-4570.

[jrtc27]

Moreover, it includes the following:

Those techniques aim to deterministically mitigate the vast majority of use-after-free vulnerabilities, aside from some edge cases where pointers are ‘hidden’ such as being XORed against a key, or residing in kernel memory.

That is true of MarkUs, but not for CHERI. With CHERI, you cannot XOR pointers against a key (unless you just XOR the address and the result is still within the representable region, but even then you can still reliably tell which allocation the capability is within). Whilst CHERIvoke didn't discuss capabilities being held by the kernel, the Cornucopia work does fully address this and ensure that all "hoarded" capabilities are also revoked. Barring any implementation bugs, there should be no such edge cases.

[jrtc27]

The final paragraph of the section also talks about Cornucopia like it's a distinct thing, but it's just an implementation of the ideas modelled in the CHERIvoke paper. Talking about them like they're different will just mislead people.

[tankist1996-spec]

In "Security analysis of CHERI ISA.pdf", the "Temporal safety" section says:

however there have been architectural extension proposals such as CHERIvoke and MarkUs which allow temporal safety enforcement built upon hardware capabilities

Firstly, CHERIvoke is just an algorithm that works on CHERI without any additional architectural extensions. Whilst the paper does propose both CLoadTags and CapDirty as extensions, they are both merely optimisations, with the former allowing capability-free cache lines to be skipped over more efficiently, and the latter removing the need to emulate CapDirty emulation in software (as is done with normal dirty tracking on architectures that only have a W bit with no corresponding D bit). Notably, the follow-up Cornocopia paper, which is to a first approximation just implementing CHERIvoke on CHERI-MIPS+CheriBSD, did not use hardware CapDirty tracking and just emulated it in software (but did make use of CLoadTags to help performance).

Secondly, MarkUs does not build upon hardware capabilities. It was written to be conservative like BDW is as a GC. Like BDW it can of course be made precise in the presence of CHERI due to no longer needing to guess whether an integer is a pointer or not, but the paper targeted a plain Intel Core i5-4570.

[tankist1996-spec]

Header	Header	Header
Cell	Cell	Cell
Cell	Cell	Cell
Cell	Cell	Cell