MID-086: Hardware Enforcement of Memory Access

Mitigation Level: Leading

Description

A lack of authenticating program memory accesses, coupled with insecure code, can give threat actors near total control over a program or machine. Threat actors can gain this control by acquiring the ability to change memory locations that a given pointer points to, manipulate return addresses that functions are jumping to (such as in a ROP attack), or alter underlying memory itself from otherwise forbidden processes.

Authenticating program memory access using hardware backed features, such as hardware-backed capabilities, can prevent this behavior. Capabilities are a way to address memory where pointers are replaced with a new data structure, called a capability, that holds both an address and access rights metadata such as read/write permissions and permissible memory bounds. This is sometimes done by physically extending register space, or by creating abstracted virtual registers consisting of 2 physical registers.

Capabilities can give an operating system memory bounds checking, memory access control, and pointer integrity checking. In the event that one of these protections are violated, the program will trap to the OS or will throw a well-defined error. Backing this enforcement in hardware involves extending these protections through methods like extending physical memory address registers, to give extra room for the capability metadata, or enforcing the memory accesses using dedicated instructions or processors so they cannot be changed in software.

One example of this can be seen by the Capability Hardware Enhanced RISC Instructions (CHERI) capability model. CHERI achieves memory protection by using a capability coprocessor, which defines compiler-managed capability registers, and tagged memory, which protects in-memory capabilities. OSes then leverage both of these features with some custom instructions (called the CHERI ISA) to implement hardware-backed capability addressing. CHERI enables the enforcement of these memory addresses by having the OS tag the physical memory address register before it is translated to a virtual memory address, ensuring that the register address cannot be tampered with after creation. The OS can then use the dedicated CHERI instructions to check that a given memory access matches the permissions found in the capability metadata. If the check is successful, then the access continues, otherwise, the OS will reject the access and fail gracefully.

IEC 62443 4-2 Mappings

SAR / EDR / HDR / NDR 3.2 – Protection from malicious code

References

[1] T. Chen, D. Chisnall. “Pointer Tagging for Memory Safety.” microsoft.com. Accessed: Mar. 24, 2025. [Online.] Available: https://www.microsoft.com/en-us/research/wp-content/uploads/2019/07/Pointer-Tagging-for-Memory-Safety.pdf?msockid=0bde5114a7906acf2a4f44ada6ab6bb4

[2] J. Woodruff, R. Watson, D. Chisnall, S. Moore, J. Anderson, B. Davis, B. Laurie, P. Neumann, R. Norton, M. Roe. “The CHERI capability model: Revisiting RISC in an age of risk.” ac.uk. Accessed: Apr. 09, 2025. [Online.] Available: https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201406-isca2014-cheri.pdf

[3] D. Chisnall. “CHERI Myths: CHERI is incompatible with safety-critical systems.” cheriot.org. Accessed: Mar. 24, 2025. [Online.] Available: https://cheriot.org/cheri/myths/2024/11/25/cheri-myths-safety-critical.html

[4] CheriBSD. “CheriBSD.” www.cheribsd.org. Accessed: Apr. 14, 2025. [Online.] Available: https://www.cheribsd.org/

[5] D. Chisnall. “CHERIoT Programmers’ Guide.” cheriot.org. Accessed: Mar. 24, 2025. [Online.] Available: https://cheriot.org/book/