ACM Queue Interviews Robert Watson On Open Source Hardware and Research

An anonymous reader writes "ACM Queue interviews Cambridge researcher (and FreeBSD developer) Robert Watson on why processor designs need to change in order to better support security features like Capsicum — and how they change all the time (RISC, GPUs, etc). He also talks about the challenge of building a research team at Cambridge that could actually work with all levels of the stack: CPU design, operating systems, compilers, applications, and formal methods. The DARPA-sponsored SRI and Cambridge CTSRD project is building a new open source processor that can support orders of magnitude greater sandboxing than current designs."

Comments

Sandbox performance

[baffled]

It's a shame AMD cut address base & length from data descriptor functionality when they released their x64 architecture. It seemed well-fit for allowing fast context-switching of sandboxed components without having to deal with slow TLB invalidation. It also would have been easier to take advantage of in a 64-bit address space, as it required chopping up the linear address space into fixed segments, and 4GB was a little tight. Hopefully we'll see more useful mainstream CPU primitives to achieve high-performance, high-scale sandboxing. I am interested to see how these instructions would be implemented at the user-level.

Re:Finally

[mikael]

Ironically it was because Intel wouldn't let Acorn computers (of the Archimedes computer and BBC Model A/B) evaluate the 80286 for future markets that Acorn and Apple formed ARM. Since ARM didn't have access to the CPU development tools that the big Silicon Valley companies had, they had to hand-design every CPU, which forced them into the low-power market.

Re:Hardware support for more sandboxes

[TheRaven64]

I work with Robert on this project. Sandboxes, as implemented by things like Chrome, have serious scalability issues. Each process needs its own page tables and TLB entries, for example, and this, combined with things like cache footprints, mean that it's not possible with current hardware to do the kinds of thing that we'd like to be able to. Chrome, for example, stops using sandboxes once you have more than about 20 tabs open for this reason, but in an ideal world, every image and every would be decoded in a separate sandbox (protecting you against bugs in libpng, libjpeg, and so on), every JavaScript scope (one per tab plus one per web worker) would be in a sandbox (protecting you against bugs in the JavaScript JIT), and so on. It's easy to imagine a typical web browser wanting a few thousand short-lived sandboxes in typical operation, and that's just for a single application. Trying to create them all using fork() or similar mechanisms will completely kill performance, so we're implementing a more fine-grained approach. The hardware's working now, so we should start trickling out more detailed publications over the next year.

I mostly work on the language side (Robert mostly does the OS bit) - the thing that got me back into academia was the ability to do language and compiler design and modify the ISA when I find things that would make life easier. I've recently started hacking a bit on the hardware though - last week I made some tweaks to the branch predictor that gave us about a 3.5% overall speedup, which made me happy as it was my first bit of hardware design.

I haven't watched the talk, but I suspect Robert also talked a bit about Capsicum, which is the pure-software approach to sandboxing that the same group implemented before I arrived. Capsicum is now shipping in FreeBSD and it's not exactly like chroot - it provides a finer-grained set of rights on file descriptors and prevents a process from creating new ones, meaning that the parent process can exactly define what parts of the system a child can touch. The Chrome sandboxing back end using Capsicum is only about 100 lines of code, which is an order of magnitude smaller than either of the Linux back ends (both of which are an order of magnitude smaller than the Windows one) and provides better isolation.