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

Hardware support for more sandboxes

[Anonymous Coward]

It wasn't clear whether Watson was talking about the need to support faster context switching and greater numbers of processes (perhaps related to the memory consumed by each thread) or something more directly related to security, such as cryptographic support.

But I only watched a few minutes before Flash crashed on me. Maybe if my desktop had one of those Cambridge research CPUs...

Re:Hardware support for more sandboxes

[phantomfive]

Yeah, exactly. As far as I can tell, their idea is just a chroot jail with some enhancements, (the only one I could find was to allow access to the file-system if they get user interaction).

Anyway, he doesn't need to spend any time explaining that CPUs change, He needs to explain why his stuff is worth implementing in hardware. Of course hardware changes, Intel adds new stuff to their processor every few years (MMX, SSE, etc). But there isn't much that's worth implementing at that level so he better make an amazing case for it.

Re:Hardware support for more sandboxes

[Lord_Naikon]

Watson wants to be able to change hardware as well as software in his research, instead of only software. He explains that changes to the hardware allow greater performance and/or capability of (for instance) the capsicum framework. Keep in mind that R. Watson is a researcher, not a product developer.

Re:Hardware support for more sandboxes

[chebucto]

A big part of the interview was about using exponentially more sandboxes. Chrome uses sandboxes for each tab, but as Watson noted, they start combining multiple tabs in single sandboxes after there are ~30 tabs open. They do this because they reach performance bottlenecks when there are that many sandboxes used.

Using the example of a browser, his goal is use nested sandboxes, and sandbox individual parts of webpages: a sandbox for a tab, and within that sandbox, sandboxes for each image, for example.

In terms of performance, though, this approach was not feasible on current processors - using the browser example again, individual images would load one at a time, similar to a browsing experience from the days of dialup.

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.

Re:Hardware support for more sandboxes

[phantomfive]

fascinating.

Re:Hardware support for more sandboxes

[TheRaven64]

Using the example of a browser, his goal is use nested sandboxes

To clarify: CHERI does not require a full ordering of trust. Part of the goal is to allow mutually distrusting parts of the program to communicate and to limit the scope of a compromise if one of the parts is problematic.

Re:Hardware support for more sandboxes

[unixisc]

Ok, so what changes to a CPU would improve support for security features like Capsicum? Newer instructions? More special purpose registers? Extra permission bits? More MIMD cores? I'd assume that the usual stuff - more registers, more cache, etc would be something desirable in any CPU, but what would a CPU need to be more friendly towards such security features?

Re:Hardware support for more sandboxes

[TheRaven64]

See the upcoming papers for more detail, but basically we're redoing how memory protection is implemented and adding a capability model in hardware. This makes it very easy to do function calls that cross a security domain and so only have access to things that were specifically delegated to them. This also means it's easier to implement some higher-level language features, such as making the interior of an object inaccessible to anything outside.

Is Slashdot on its deathbed?

[Anonymous Coward]

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:Umm You might want to hold-off

[Hognoxious]

~ ... Irving Berlin, Joe DiMaggio ... /#

Avengers Compile!

[Impy the Impiuos Imp]

> "CPU design, operating systems, compilers, applications, and formal methods."

Compiler comes before OS in that hierarchy.

Re:Avengers Compile!

[TheRaven64]

Not necessarily. I am the person working on the compiler(s) he's talking about, and chronologically it goes more CPU, assembler, OS, compiler, CPU, OS... Before the compiler can do anything interesting, for example, the OS must be modified to understand the extra CPU state (context switch code, in particular). Both the OS and compiler design then feed back into the CPU design. One of the nicest things about this project is that we can modify any part of the stack, so the hierarchy isn't nearly as apparent as it normally is, where you're modifying one component and the other two are fixed.

We're All Hungover

[raftpeople]

All the people of value were at the party last night, you didn't get the invite?

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:Umm You might want to hold-off

[Paradise Pete]

You made try to reread the OP in a way that makes it fit the song. I failed. :-)

How I hope the interview started

[93 Escort Wagon]

I hope the first statement from the interviewer was either

"Mr. Watson, come here - I want to see you"

or

"Come, Watson, the game is afoot!"

Re:How I hope the interview started

[TheRaven64]

"Mr. Watson, come here - I want to see you"

Given that both John and Robert Watson have doctorates, why would either be addressed as Mr?

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.

Geez, I was all excited because...

[DoctorBonzo]

I misread the story headline as an interview with *IBM*s Watson.

It's a video, just like the Turing Award Lecture..

[girlinatrainingbra]

Sadly, it's a link to video, just like the Turing Award Lectures have been for recent awards, e.g. Barbara Liskov in 2008 link to video: http://amturing.acm.org/vp/liskov_1108679.cfm

.

Why couldn't they get the winner to provide a text, or LaTeX, or PDF, or even HTML version of their talk/speech, and make it easier to visually scan and re-read, rather than worry about lame encoder/video/flash/html5 issues and plug-ins?

.

You'd think a society like the ACM could know and use computing machinery, wouldn't you, or is that expecting too much in this world? And you'd think that people on /. would be all over this topic, whereas there are NO comments rated over (or even AT) 2 points currently (9:40 PM PDT, 2012-10-20 Saturday in California).

.

mod parent back up! resuscitate!!!

[girlinatrainingbra]

Even sadder is that you comment is currently modded down to a score of (-1) currently! I completely agree with you that this is a good hard-core tech topic and I'd like it if there were more comments and conversation on this board. It makes no sense to have your comment modded down when you are definitely on point about this... If I had moderator points, I'd mod your comment back up to the living.

.

At least the SSL article has over 100 posts on it, but the 21st IOCCC Source Code Released article also only has 22 posts on it. Either this means coders are actually out on Friday and Saturday nights (not zehr likely ;>) ) or the population at this watering hole is not what it purports to be...

Re:Finally

[magnusk]

Hmm, I think you have a few things wrong and/or misleadingly stated.

In the early 1980s Acorn evaluated CPUs for their next-generation product. 80286 was released in 1982 February and was readily available on the market so there was no need to get Intel's cooperation to evaluate it. But, Acorn did want to license the 80286 core and make changes to it, which Intel rejected. All the evaulated CPUs were deemed inadequate, so in 1983 October Acorn started development of Acorn RISC Machine.

The goal of the ARM architecture was high performance. (On production release it out-performed the still-current 80286.) The device was simple because of the limited design resources, and therefore low-power, but for it to be quite as low power as it turned out to be was an entirely unexpected accident.

Apple officially became part of the the ARM project when Acorn spun off ARM Ltd in 1990 November, by which time the 80486 was on the market. Apple's interest was to continue development of low-power CPUs for their Newton handheld, for which the 80x86 line was unsuitable.