In "Security analysis of CHERI ISA.pdf", section "Executable capability bounds" refers to LOAD_DATA and LOAD_CAP permissions. In ISAv7 we call them (Permit_)Load and (Permit_)Load_Cap(ability), and Morello calls them Load and LoadCap. Calling it LOAD_DATA is confusing and might mislead readers into thinking it doesn't apply to capabilities. Please instead call it LOAD to reference the correct name of it.

In "Security analysis of CHERI ISA.pdf" under "Executable Capability Bounds", $pcc and $cgp are mentioned several times. Whilst PCC is called that on CHERI-MIPS, CHERI-RISC-V and Morello, the $-prefix is MIPS-specific, and our sketch of CHERI-x86-64 uses CIP instead of PCC given x86 calls it EIP/RIP rather than PC. As for CGP, that's even more MIPS-specific; CHERI-RISC-V directly accesses the captable with an AUIPCC/CLC sequence like normal RISC-V even though CGP exists as a register name (but will be used in other ABIs), Morello does something similar with an ADRP/LR sequence like normal AArch64 and CHERI-x86-64 would use a single CIP-relative MOV.

Please therefore either generalise this to talk more abstractly about being PCC-relative (even though x86 uses RIP-relative addressing, calling it PC-relative is acceptable, so I think PCC-relative is fine as a term for x86, so long as the register isn't actually stated to be called PCC) or specify that this is specifically for CHERI-MIPS and that whilst the model is similar there are differences in nomenclature and implementation.

The second paragraph of "Security analysis of CHERI ISA.pdf" says "These capabilities are 128-bit extensions of 64-bit pointers", but that is not true. CHERI as a model works with any address space size and any capability size greater than that (though you likely want a power-of-two if you want any hope of things working, and you need enough bits to have useful precision), and we have a 32-bit RISC-V version implemented. Please either generalise this accordingly or clarify that you are talking about specific instantiations of CHERI.

In "Security analysis of CHERI ISA.pdf" under "munmap doesn't check the tag of pointers", there are the following issues:

1. The first paragraph says "The problem was that munmap didn't make sure the base pointer is indeed in the capability bounds", but as we pointed out on the original issue and is mentioned elsewhere in this section it did check the bounds, but the capability had been incremented outside its representable region, so the bounds had moved such that the address was in bounds with the tag now cleared, and the problem was that the tag wasn't being checked in munmap.

2. The PoC has "fat pointer (ptr+cap)" in one of the comments, which is misleading about what a fat pointer is for CHERI. For CHERI, the capability is the pointer, and can be thought of as "address + metadata", but calling the metadata the capability and/or calling the address the pointer is wrong and risks misleading readers.

2 is repeated later in "Stealing capabilities, signing gadgets" with "i.e. - copy the whole fat pointer, capability and raw pointer" and "shallow copy a capability and pointer and use this pointer in another functionality (while keeping the capability intact)", as well as in "Mitigated ideas" with "every change to the capability/pointer", although perhaps this one is saying that the two are equivalent, not that you're changing one or the other (given the earlier confusion it's unclear which was intended)?

In "Security analysis of CHERI ISA.pdf", section "Case study examples: CheriBSD and JSC" says:

It’s worth noting that qtwebkit and JSC do not support JIT or garbage collection

Whilst the table goes on to clarify somewhat (although not as clearly as it could) that this is a MIPS-specific restriction (more accurately MIPS64-specific, as there is a 32-bit JIT implementation), the main body should be clear about this too otherwise it will mislead. AArch64 does have a JIT implementation, although a Morello JIT would still need to be developed.

In "Security analysis of CHERI ISA.pdf", section "Stealing capabilities, signing gadgets", there is the following description:

The next lines do a logical or on a capability taken from $c3 and then $c1 with 3 and saves it again at $c1+0x16

referring to the code sequence:

clc      $c1, zero, 0($c3)
clc      $c2, zero, 16($c1)
cgetaddr at, $c2
ori      at, at, 3
csetaddr $c2, $c2, at
csc      $c2, zero, 16($c1)

Firstly, it should say $c1+0x16 not $c1 in the description. Secondly, "taken from" is vague and could be taken as a register-register move rather than a load; I would suggest saying "loaded from/via" (and use "stores" rather than "saves", though that one at least is not ambiguous).

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

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.

testme.txt