Hacker News Reader

Comment by gumby | Hacker News Reader

A big one is the cost of defense against forgery. A capability is essentially an index or pointer into a table in kernel space (much like an FD as another poster mentioned).

The traditional mitigation is to use hardware tagging and permit the tag bits to be set only via a privileged instruction, e.g. Multics. The x86 segmented memory model also allowed this, and I used this to build some experimental SUID memory-mapped the 1990s (you could call into them via special gates, but not read the instruction memory, for example). Although you those memory models are still supported on x86 for back compatibility I don’t believe they are particularly fast any more, unfortunately.

Edit: The lowrisc (RISC v) folks are implementing tagged memory also btw

View on HN

Capabilities are either unforgeable or unguessable, depending on your vantage point: https://capability.party/philosophy/2017/07/29/unforgeable-v...

Seems like you're talking about hardware capabilities, which haven't really been tried seriously since Intel's iAPX 432 processor in the early 80's. It failed miserably due to horrible performance, but some argue that the performance could have been fixed had they been given a second shot at it.

Modern capability systems don't rely on hardware support and performance issues aren't usually cited as a problem with capabilities. In fact, capabilities can often perform better than ACLs since ACLs tend to require performing an expensive access check on every operation.

Thought it worth pointing out that Cheri are giving hardware capabilities another go.

http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

yes, I was talking about hardware tagging, else you can’t protect capabilities solely in user space. Intel had tagged memory in the 90’s era i960 as well and, as I edited my comment to mention (thanks to your comment!) several others including most recently RISC-V).

IMHO the 432 had other structural problems and it wasn’t the tagging that killed it but it had enough problems that this is definitely not worth disagreeing about — perhaps that was indeed the straw that broke that camel’s back.

In userspace, you can protect capabilities within a process by forcing people to use a capability-safe language, or you can let people use whatever and instead focus on protecting capabilities between processes (or between a process and the kernel, or between machines).

But by definition you can’t protect capabilities between processes without the assistance of the kernel, no?

Reply on news.ycombinator.com