Add experimental section describing design points for using DMA with CHERI #130
Conversation
| \subsubsection{DMAs with control information streamed externally} | ||
| The AMD (Xilinx) LogiCORE IP AXI DMA~\cite{amd-logicoredma} is an example of an M2S/S2M DMA, comprising a memory access port plus streaming sources and sinks for both data and control transactions. | ||
| In its most basic mode it can operate with transaction information in MMIO registers, as the previous category. | ||
| However for greated performance transaction information (addresses, lengths) can alternatively be streamed into a control port. |
There was a problem hiding this comment.
| However for greated performance transaction information (addresses, lengths) can alternatively be streamed into a control port. | |
| However for greater performance transaction information (addresses, lengths) can alternatively be streamed into a control port. |
| However for greated performance transaction information (addresses, lengths) can alternatively be streamed into a control port. | ||
| This enables custom logic to control and steer memory traffic. | ||
|
|
||
| \subsubsection{Descriptor-based DMA} |
There was a problem hiding this comment.
It may be worth splitting this discussion. Descriptors as presented both augment the control information discussed (with strides) and can get placed in memory. These aspects are separable.
| It may be desirable to augment or replace the IOMMU with some other structure which instead uses the capability model, along the same lines of using CHERI for protection and the MMU for translation. | ||
| Examples of such schemes are given in Cheng and Markettos~\cite{DBLP:conf/micro/MarkettosBBNMW20, cheng2025-capchecker}. | ||
|
|
||
| Where possible, a preferable design point is to integrated CHERI support into a bus-mastering device such that the hardware can be trusted to manipulate capabilities correctly. |
There was a problem hiding this comment.
| Where possible, a preferable design point is to integrated CHERI support into a bus-mastering device such that the hardware can be trusted to manipulate capabilities correctly. | |
| Where possible, a preferable design point is to integrate CHERI support into a bus-mastering device such that the hardware can be trusted to manipulate capabilities correctly. |
| Examples of such schemes are given in Cheng and Markettos~\cite{DBLP:conf/micro/MarkettosBBNMW20, cheng2025-capchecker}. | ||
|
|
||
| Where possible, a preferable design point is to integrated CHERI support into a bus-mastering device such that the hardware can be trusted to manipulate capabilities correctly. | ||
| In this instance we are able to run untrusted I/O software stack safely on trustworthy CHERI-enabled hardware. |
There was a problem hiding this comment.
Mention something about attestation? If we're worried about malicious hot-plug devices claiming to honor CHERI invariants, we need some way to decide whether we believe that.
| The question arises how to compose them. | ||
| Below we describe some different levels of utilizing capabilities with DMA. | ||
|
|
||
| \subsubsection{Level 0: DMA clears tags} |
There was a problem hiding this comment.
This has implications on the software driver model, too: a completely CHERI-oblivious DMA engine grants the authority to access memory given only an integer address, even if it cannot forge capabilities capturing that authority. As such, access to such DMA engines must be carefully controlled and restricted to TCB components.
| these would not map directly to the bounds of a capability. | ||
|
|
||
| An implementation using DMA using MMIO registers would extend address registers to capabilities, while one using descriptors would need to change the descriptor format to include a capability. | ||
| This may cause downstream effects, such as requiring descriptors to be padded and aligned to multiples of the capability size, which are specific to the DMA controller being modified. |
There was a problem hiding this comment.
If descriptors are stored in memory, the DMA engine's access to them would, ideally, also be constrained by capabilities.
| This may not be an issue for small buffers, but may become one for larger buffers. | ||
| Additionally alignment may depend on external factors outside our control. | ||
| For example, it may be necessary to restart partial transactions. | ||
| Conceptually it would be possible to increment the address and reduce the bounds, but this could runs into precision difficulties. |
There was a problem hiding this comment.
| Conceptually it would be possible to increment the address and reduce the bounds, but this could runs into precision difficulties. | |
| Conceptually it would be possible to increment the address and reduce the bounds, but this could run into precision difficulties. |
| An implementation using DMA using MMIO registers would extend address registers to capabilities, while one using descriptors would need to change the descriptor format to include a capability. | ||
| This may cause downstream effects, such as requiring descriptors to be padded and aligned to multiples of the capability size, which are specific to the DMA controller being modified. | ||
|
|
||
| \subsubsection{Level 2: unifying length and bounds} |
There was a problem hiding this comment.
This section conflates "unifying length and bounds" and re-bounding provided capabilities as part of a DMA transaction. I think those should be pulled apart.
| \item arrange such that structurally there is no ambiguity at the point of check as to which address space a capability refers. | ||
| \end{enumerate} | ||
|
|
||
| In the first case, bits that travel within the in-memory capability are used to identify its address-space identifier (ASID), such as a `color' (see section~\ref{app:exp:peripherals}). |
There was a problem hiding this comment.
These intra-capability ASID bits are meant to be interpreted by an IOMMU, SIOV-style, I presume?
| \item carry around the address space stored as bits inside the capability, or | ||
| \item maintain the color as external metadata that is supplied to wherever a capability needs to be checked, or | ||
| \item arrange such that structurally there is no ambiguity at the point of check as to which address space a capability refers. | ||
| \end{enumerate} |
There was a problem hiding this comment.
It's probably worth discussing the current state(s) of play in non-CHERI systems, especially with PCIe and virtualization-supporting gateware technologies (with fabric-enforced device identifiers and per-device ASID namespaces) and the corresponding software dances to keep IOMMUs and MMUs sufficiently in sync.
Added a section about CHERI and DMA, describing some options and setting the scene for existing two sections on physical addresses and capability colouring.