Cheri Tagged Memory

Q & A

  • How two layers tag cache work? How to update the nodes in the layers?

  • How is the tag being set?

    • all caps being originated from one cap: the cap covers entire address space.
    • Each new pointer is created via explict capability.
    • Local pointers
    • Pointers to Global
    • Pointers to Heap

  • How can we propagate the tag?

2017 paper:

cache figure

Tags is cached with the memory they describe within the cache hierarchy.

SBT: single-bit tag

MBT: multi-bit tag. 1,2,3,[^2c15],4,5

“We rebuilt the tag controller engine in the open-source CHERI processor (http://www.bericpu.org/), and added perfor- mance counters to the CHERI cache. CHERI is instantiated with 32KiB L1 caches and a 256KiB L2 cache, all 4-way set associative with 128-byte lines. CHERI requires a tag bit for each 256-bit word, resulting in a natural caching amplification factor of 256. Our new tag controller includes a lookup engine backed by a 32KiB 4-way set-associative cache with 128-byte lines, matching the burst size in the CHERI system. Since each cached tag bit covers 256 bits of data memory, each 128- byte line in the tag-table cache provides tags for 32 kilobytes of data memory. We restricted ourselves to a standard cache instantiation for the tag controller which did not allow silent- write elimination so this feature was not evaluated in hardware”

CLoadTags

Since ISAv7:

alpha2: “We have added a new experimental CLoadTags instruction that allows tags to be loaded for a cache line without pulling data into the cache.”

alpha3: “It is clarified that CLoadTags instruction must provide cache coherency consistent with other load instructions. We recommend “non-temporal” behavior, in which unnecessary cache-line fills are avoided to limit cache pollution during revocation.”

Inspecting Tags

ISAv7 Ch6.6.3 instructions that stored a capability will set the tag bit of the stored capability.

Tagged Mem on reset

ISAv7 ch3.5.2 : should be cleared on CPU reset.

“We instead rely on firmware or software supervisors to ensure that pages placed into use, especially with untrustworthy code, have been properly cleared”

ISAv7 ch4.6: “the firmware, hypervisor, or operating system can in principle ensure that tags are cleared on memory before it is exposed to untrustworthy software, in much the same way that they will normally ensure that memory is cleared to prevent data leaks before memory reuse.”

Tagged mem on process creation

CheriABI6 ch4.3 execve system call.

Legacy programs: store on initial stack: argument, environment, ELF auxiliary argument arrays; adjust initial stack pointer [^3c16], [^3c47]

CheriABI process: all pointers are bounded capabilities.

  • C run-time altered to take a pointer to the ELF auiliary argument array and extend it to contain pointers to the argument and environment arrays (argv, environ) as well as argument and environment counts (argc, envc), rather than using knowledge of the stack layout and walking off the end of the environment array to find the auxiliary argument vector.

  • after loaded, the address spaces are futhur changed(including dynamic laoding) via system calls.

    // sys/compat/cheriabi/cheriabi_syscalls.c: 68
	"cheriabi_execve",			/* 59 = cheriabi_execve */

// compat/cheriabi/cheriabi_misc.c: 178
int
cheriabi_execve(struct thread *td, struct cheriabi_execve_args *uap)
{
	struct image_args eargs;
	struct vmspace *oldvmspace;
	int error;

	error = pre_execve(td, &oldvmspace);
	if (error != 0)
		return (error);
	error = exec_copyin_args(&eargs, uap->fname, UIO_USERSPACE,
	    uap->argv, uap->envv);
	if (error == 0)
		error = kern_execve(td, &eargs, NULL);
	post_execve(td, error, oldvmspace);
	return (error);
}

Pointer provenance

  • “Every valid pointer is derived from precisely one object”

    • malloc()
    • stack allocation

  • Bounds are never implicitly changed

Capability: Provenance-carrying integers

searching, storing, and updating big dataflow tags. 2008. MICRO.

  1. Secure program execution via dynamic information flow tracking. 2004, ASPLOS. ↩
  2. A small cache of large ranges: Hardware methods for efficiently ↩
  3. Hardware enforcement of application security policies using tagged memory. 2008, OSDI. ↩
  4. E. Witchel, J. Cates, and K. Asanović, Mondrian memory protection. ACM, 2002, vol. 30, no. 5 ↩
  5. D. Y. Deng, Flexible and efficient accelerator architecture for runtime monitoring. Cornell University, 2016. ↩
  6. CheriABI UCAM-CL-TR-932, 2019. ↩
Created Sep 27, 2019 // Last Updated Jul 3, 2020

If you could revise
the fundmental principles of
computer system design
to improve security...

... what would you change?