Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

ACM Queue Interviews Robert Watson On Open Source Hardware and Research

timothy posted about 2 years ago | from the whole-shebang dept.

Operating Systems 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."

cancel ×


Sorry! There are no comments related to the filter you selected.

Umm You might want to hold-off (-1)

Anonymous Coward | about 2 years ago | (#41714419)

God's gonna issue design orders. Unless you want to cancel your work, you might want to wait. You guys need a natural disaster or something as proof?

God says...

knots wrinkle next recipe unpunished guardianship converting
service overjoyed infection In mire departing guidance
quieter lessons engine relations surpasses agents knowing
etext90 transferred discussion solecism heavily recognising
fairly sets cleaved ABOUT sword ghosts EIN Coeternal Hope
won computer talkers whichsoever firm trust sprung helpful
otherwise stricken inheritance proprietary theatre slew
built metres unanxious grieving Hereat smooth throne oppose
distribution absolute consecrateth 1921 err retaineth
recipe Isn't_that_special relapse works modesty measurable
beguile feet If_had_my_druthers Verily well-spring wickedly
cabinets I_didn't_see_that umm per become exhalation reposeth
gold resisted unanxious women omnipotent prose smile Roman
communication free-will use replace Pages putting commenders
94 milder commandeth replacing recesses

Re:Umm You might want to hold-off (1)

Hognoxious (631665) | about 2 years ago | (#41714725)

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

Re:Umm You might want to hold-off (1)

Paradise Pete (33184) | about 2 years ago | (#41715705)

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

Re:Umm You might want to hold-off (0)

Anonymous Coward | about 2 years ago | (#41718791)

That's because the OP is a screwball. He started his post with "God's". That's the only clue you need.

Finally (0)

Sulphur (1548251) | about 2 years ago | (#41714441)

There is an OxBridge processor. (Or is it DarBridge?)

Re:Finally (0)

Anonymous Coward | about 2 years ago | (#41714661)

ARM is a little CPU vendor that spun off of Cambridge as well...

Re:Finally (2)

mikael (484) | about 2 years ago | (#41716937)

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:Finally (1)

magnusk (569300) | about 2 years ago | (#41754063)

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.

Hardware support for more sandboxes (1)

Anonymous Coward | about 2 years ago | (#41714529)

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 (1)

phantomfive (622387) | about 2 years ago | (#41714933)

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 (0)

Anonymous Coward | about 2 years ago | (#41715543)

In terms of ease-of-use, at least, Hurd promises better sandboxing through its VFS - see [] - especially from 1:00 to 6:00, and 9:23 to ~12:00

Re:Hardware support for more sandboxes (1)

Lord_Naikon (1837226) | about 2 years ago | (#41715555)

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 (3, Interesting)

TheRaven64 (641858) | about 2 years ago | (#41720881)

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 (1)

phantomfive (622387) | about 2 years ago | (#41722035)


Re:Hardware support for more sandboxes (1)

unixisc (2429386) | about 2 years ago | (#41758513)

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 (1)

TheRaven64 (641858) | about 2 years ago | (#41761955)

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.

Re:Hardware support for more sandboxes (1)

chebucto (992517) | about 2 years ago | (#41715831)

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 (1)

TheRaven64 (641858) | about 2 years ago | (#41726971)

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.

Is Slashdot on its deathbed? (1, Interesting)

Anonymous Coward | about 2 years ago | (#41714711)

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:Is Slashdot on its deathbed? (-1)

Anonymous Coward | about 2 years ago | (#41714871)

well its a boring article because, apparantly, the team at Cambridge is not implementing "Social Media" at the processor level, to the dismay of many.

We're All Hungover (1)

raftpeople (844215) | about 2 years ago | (#41714931)

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

It's Saturday! (0)

Anonymous Coward | about 2 years ago | (#41715531)

Cartoons and masturbating in your parent's basement are more interesting than this.

Re:Is Slashdot on its deathbed? (0)

Anonymous Coward | about 2 years ago | (#41716609)

It does look interesting, but it's a video. I'll probably watch it later when I've got some free time.

Re:Is Slashdot on its deathbed? (0)

Anonymous Coward | about 2 years ago | (#41718233)

Slashdot doesn't post many hard computer science stories these days. Maybe 1/10. Of the remaining 9, 5 are soft stories about hot-button issues, military technology, etc, and 4 are about IT corporations' corporate machinations. Meanwhile the stories that are actually 'news for nerds' get ~20 comments each.

Hell, the story about the FSF award nominations the other day had _maybe_ 20 comments, the vast majority of which were gibberish, offtopic, or otherwise generally stupid. There weren't even any good flamewars about the GPL. It was just dilettante-city over there. And if you can't have a good debate about FSF awards here, then where the frack can you? Argh.

mod parent back up! resuscitate!!! (1)

girlinatrainingbra (2738457) | about 2 years ago | (#41719439)

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...

Avengers Compile! (1)

Impy the Impiuos Imp (442658) | about 2 years ago | (#41714849)

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

Compiler comes before OS in that hierarchy.

Re:Avengers Compile! (1)

TheRaven64 (641858) | about 2 years ago | (#41720893)

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.

integer overflow trap (0)

Anonymous Coward | about 2 years ago | (#41715293)

Integer overflow is the new buffer overflow. See for many examples. We need CPU's that can trap when it happens. Yes, we can have the compiler generate checks instead, but nobody does it because of the code bloat and slowdown involved, unless they EXPECT overflow and use a bignum library. But it's the unexpected overflow that kills you, so zero-overhead checking should be provided by the hardware and enabled all the time. In cases where you actually want wraparound arithmetic, use special datatypes for the purpose.

Sandbox performance (2)

baffled (1034554) | about 2 years ago | (#41715395)

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.

How I hope the interview started (1)

93 Escort Wagon (326346) | about 2 years ago | (#41715989)

I hope the first statement from the interviewer was either

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


"Come, Watson, the game is afoot!"

Re:How I hope the interview started (0)

Anonymous Coward | about 2 years ago | (#41718263)

And you already knew that Watson is a name of a character in a detective story series?

Good for you, thanks for pointing that out. You really contributed to this discussion. Make sure to put in the same effort next time.

In case you can't tell, I'm being facetious.

Re:How I hope the interview started (1)

TheRaven64 (641858) | about 2 years ago | (#41726977)

"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?

Protection is a software issue (0)

Anonymous Coward | about 2 years ago | (#41717091)

While have more hardware support for isolation is always nice, there is a lot of sandboxing that could be done in software, which we currently don't. Techniques such as SFI/CFI/XFI are only now starting to get understood outside of a narrow circle of researchers (Google Native Client is an SFI system for instance, I don't understand why that does not get mentioned in the video when there is so much talk about Chrome), and if we can solve this in software we don't have to replace all our existing hardware. This old and short paper : argues well that "protection is a software issue" and is still worth a read.

Re:Protection is a software issue (0)

Anonymous Coward | about 2 years ago | (#41718877)

Have you looked at GNU/Hurd? They claim to have a model that makes sandboxing much more trivial to implement. See my earlier AC comment here [] .

Nota bene - I don't know if what the Hurd team is claiming will work on a scale that Watson is talking about, where there are exponentially more sandboxes than we use today. I need to read up on it more. But it is interesting.

Geez, I was all excited because... (1)

DoctorBonzo (2646833) | about 2 years ago | (#41718393)

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

Re:Geez, I was all excited because... (0)

Anonymous Coward | about 2 years ago | (#41718809)

An interview with an actual computer scientist about cutting-edge research on emerging mainstream trends eg pervasive sandboxing. That is less interesting than a gimmicky interview with a prototype natural-language machine optimized for a TV game show?


The IBM Watson thing would be a curiosity that I fully admit I'd read, but this interview - watch it! - is actually quite interesting and thought-provoking.

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

girlinatrainingbra (2738457) | about 2 years ago | (#41719409)

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: []


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).


Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>