ACM Queue Interviews Robert Watson On Open Source Hardware and Research 37
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."
Is Slashdot on its deathbed? (Score:1, Interesting)
This story has been up for about an hour now. It's about several topics that anyone wit a passion for computer science, software development, hardware development or computing in general should find very interested. It even involves one of the most important open source contributors ever, Robert Watson.
Yet aside from this comment, there are only three others! One of the comments is complete gibberish. One of the remaining two, the one by Sulpher, is absolutely useless because it adds nothing to the discussion. The third comment actually has much value, but it's not easily visible because it was posted anonymously.
What is happening here at Slashdot? In the past, a story like this would have at least several hundred comments after an hour. There'd be a lot of great discussion. But today, we see basically nothing.
Has everyone fled to Reddit or Hacker News? Is that why there is so little discussion here at Slashdot these days? Is there merely nobody of value left here?
Re:Hardware support for more sandboxes (Score:4, Interesting)
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.