4 ms·
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 m
by kentonv 9y ago
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.
- eb3c90 9y agoThought it worth pointing out that Cheri are giving hardware capabilities another go. http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
- gumby 9y agoyes, 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.
- kentonv 9y agoIn 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).
- gumby 9y agoBut by definition you can’t protect capabilities between processes without the assistance of the kernel, no?