Re: Capabilities, Anybody?

BGB <cr88192@gmail.com> wrote:

There CHERI designs on silicon in existence
 
https://www.morello-project.org/

Member of the CHERI team here...

Main open question is if they can deliver enough on their claims in a
way that justifies the cost of the memory tagging (eg, where one needs
to tag whether or not each memory location holds a valid capability).

Crudely speaking, it's 1/128 of memory so 0.78%.  Through use of
a tag cache you don't need to have a speciifc 129th bit on your DRAM
(although that's an option, like ECC) but can just wall off a piece of
regular DRAM and use it for a tag table that's accessed via the tag cache.
You only pay the cost for DRAM you actually have (eg one tag table per DIMM,
sized for that DIMM).

The tag cache can also be compressed[1] so that if a memory page has no
capabilities you don't need to store tags for it.  This reduces tag cache
bandwidth further.

As I see it, "locking things down" would likely require turning things
like "malloc()/free()", "dlopen()/dlsym()/...", etc, into system calls
(and generally giving the kernel a much more active role in this process).

You don't need memory allocations to be system calls, because capabilities
can be manipulated in userspace (which is a key design goal).  ie if
malloc() possesses a capability to 1MB of memory and a client requests 100
bytes, it can take its 1MB capability, offset the base to point to the start
of the allocation, set the offset to zero, and shrink the top to be
base+100, and then return that 100-byte capability.

In a Unix OS, userspace malloc() does occasionally need to make a syscall -
when it runs out of memory pages on hand it has to ask the kernel to
allocate it some more via mmap().  But this is orthogonal to use of
capabilities (which are virtually addressed in such a system).

For dynamic linking, you need something that holds capabilities that allow
you to turn read-write memory into read-execute memory.  That can be part of
the dynamic linker or part of the OS.  Since you are typically making
syscalls to read the shared library from disc anyway, as well as marking RW
pages as RX pages in the page table, the OS is already involved.

But, say, note that it would not be sufficient, say, for things like
sandboxing hostile code within a shared address space with another
program that needs to be kept protected.
 
 
Granted, the strength could likely be improved (in the face of trying to
prevent hostile code from being able to steal capabilities) through
creative use of ASLR. Along with ABI features, such as "scratch register
scrubbing" (say, loading zeroes into scratch registers on function
return, such as to prevent capabilities from being leaked through via
registers), marking function pointers as "Execute Only" etc.
 
As noted, a capability system would likely still be pretty strong
against things like buffer overflows (but if only being used to mitigate
buffer overflows, is a bit overkill; so the main "interesting" case is
if it can be used to make an "unbreakable sandbox" for potentially
hostile machine code).

Code capabilities prevent a lot of control flow attacks, because you can
only execute code you have capabilities to.  For example you're in a
function - you possess a return address capability (which has bounds based
on your local environment or compartment you're in) so you can manipulate
the address of that return address, but you can't jump to arbitrary code and
you can't forge return addresses.  So no stack smashing, no ROP/JOP attacks,
etc.

Through setting the bounds on a code capability you can sandbox small pieces
of code to a function granularity, which is more efficient than typical MMU
sandboxing.

*: If it is possible to perform a Load or (worse, Capability Load)
through a function pointer, this is likely to be a significant attack
vector. Need to make it so that function pointers can only be used to
call things. Protecting against normal data loads would be needed mostly
to try to prevent code from being able to gain access to a known pointer
and possibly side-step the ASLR (say, if it can figure out that the
address it wants to access is reachable from a capability that the code
has access to).

You can't arbitrarily change data to code capabilities - they are different
types.

It is likely that the capability memory tagging would need to be managed
by the L2 cache. Would need some mechanism for the tag-bits memory (say,
2MB for 256MB at 1b per 16B line). Would also need to somehow work this
flag bit into the ringbus messaging.

AXI has user fields which can be used for sending capabilities across the
interconnect, through third party AXI IPs like muxes, arbiters, etc.

Theo

[1] https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201711-iccd2017-efficient-tags.pdf