|
| 1 | +[appendix] |
| 2 | +== CHERI System Implications |
| 3 | + |
| 4 | +CHERI processors need memory systems which support the capability validity tags in memory. |
| 5 | + |
| 6 | +There are, or will soon be, a wide range of CHERI systems in existence from tiny IoT devices up to server chips. |
| 7 | + |
| 8 | +There are two types of bus connections used in chips which contain CHERI CPUs: |
| 9 | + |
| 10 | +. Tag-aware busses, where the bus protocol is extended to carry the tag along with the data. This is typically done using a user defined bit in the protocol. |
| 11 | +.. These busses will read tags from memory (if tags are present in the target memory) and return them to the requestor. |
| 12 | +.. These busses will write the tag to memory as an extension of the data write. |
| 13 | +. Non-tag aware busses, i.e. normal non-CHERI aware busses. |
| 14 | +.. Reads of tagged memory will not read the tag. |
| 15 | +.. Writes to tagged memory will clear the tag of any CLEN-aligned CLEN-wide memory location where any byte matches the memory write. |
| 16 | + |
| 17 | +The fundamental rule for any CHERI system is that the tag and data are always accessed atomically. For every naturally aligned CLEN-wide memory location, it must never be possible to: |
| 18 | + |
| 19 | +. Update any data bytes without also writing the tag |
| 20 | +.. This implies clearing the tag if a non-CHERI aware bus master overwrites a capability in memory |
| 21 | +. Read a tagged value with mismatched (stale or newer) data |
| 22 | +. Set the tag without also writing the data. |
| 23 | + |
| 24 | +NOTE: Clearing tags in memory does not necessarily require updating the associated data. |
| 25 | + |
| 26 | +=== Small CHERI system example |
| 27 | + |
| 28 | +[#small_cheri_system] |
| 29 | +.Example small CHERI system with local capability tag storage |
| 30 | +image::small_cheri_system.drawio.png[width=80%,align=center] |
| 31 | + |
| 32 | +This example shows a minimum sized system where only the local memory is extended to support capability tags. |
| 33 | +The tag-aware region is highlighted. |
| 34 | +All tags are created by the CHERI CPU, and only stored locally. The memory is shared with the system, probably via a secure DMA, which is not tag aware. |
| 35 | + |
| 36 | +Therefore the connection between CPU and memory is tag-aware, and the connection to the system is not tag aware. |
| 37 | + |
| 38 | +All writes from the system port to the memory must clear any memory tags to follow the rules from above. |
| 39 | + |
| 40 | +=== Large CHERI system example |
| 41 | + |
| 42 | +[#large_cheri_system] |
| 43 | +.Example large CHERI system with tag cache |
| 44 | +image::large_cheri_system.drawio.png[width=80%,align=center] |
| 45 | + |
| 46 | +In the case of a large CHERI SoC with caches, all the cached memory visible to the CHERI CPUs must support tags. |
| 47 | +All memory is backed up by DRAM, and standard DRAM does not offer 129-bit words and so a typical system will have a tag cache IP. |
| 48 | + |
| 49 | +A region of DRAM is reserved for CHERI tag storage. |
| 50 | + |
| 51 | +The tag cache sits on the boundary of the tag-aware and non-tag-aware memory domains, and it provides the bridge between the two. |
| 52 | +It stores tags locally in its cache, and if there is a miss, it will create an extra bus request to access the region of DRAM reserved for tag storage. |
| 53 | +Therefore in the case of a miss a single access is split into two - one to access the data and one to access the tag. |
| 54 | + |
| 55 | +The key property of the tag cache is to preserve the atomic access of data and tags in the memory system so that all CPUs have a consistent view of tags and data. |
| 56 | + |
| 57 | +The region of DRAM reserved for tag storage must be only accessible by the tag cache, therefore no bus initiators should be able to write to the DRAM without the transactions passing through the tag cache. |
| 58 | + |
| 59 | +Therefore the GPUs and peripherals cannot write to the tag storage in the DRAM, or the tagged memory data storage region. |
| 60 | +These constraints will be part of the design of the network-on-chip. |
| 61 | +It _is_ possible for the GPU and peripherals to read the tagged memory data storage region of the DRAM, if required. |
| 62 | + |
| 63 | +NOTE: It would be possible to allow a DMA to access the tagged memory region of the DRAM directly to allow swap to/from DRAM and external devices such as flash. |
| 64 | + This will require the highest level of security in the SoC, as the CHERI protection model relies on the integrity of the tags, and so the root-of-trust will need to authenticate and encrypt the transfer, with anti-rollback protection. |
| 65 | + |
| 66 | +For further information on the tag cache see cite:[tagged-memory]. |
| 67 | + |
| 68 | +<<< |
| 69 | + |
| 70 | +=== Large CHERI pure-capability system example |
| 71 | + |
| 72 | +[#large_cheri_purecap_system] |
| 73 | +.Example large CHERI system with only tag-aware bus masters |
| 74 | +image::large_cheri_purecap_system.drawio.png[width=80%,align=center] |
| 75 | + |
| 76 | +In this example every DRAM access passes through the tag cache, and so _all_ bus masters are tag-aware and can access the tagged memory if permitted by the network-on-chip. |
| 77 | + |
| 78 | +The system topology is simpler than in xref:large_cheri_system[xrefstyle=short]. |
| 79 | + |
| 80 | +There is likely to be a performance difference between the two systems. |
| 81 | +The main motivation for xref:large_cheri_system[xrefstyle=short] is to avoid the GPU DRAM traffic needing to look-up every tag in the tag cache, potentially adding overhead to every transaction. |
0 commit comments