Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Unix BSD Hardware

ACM Queue Interviews Robert Watson On Open Source Hardware and Research 37

Posted by timothy from the whole-shebang dept.
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."
This discussion has been archived. No new comments can be posted.

ACM Queue Interviews Robert Watson On Open Source Hardware and Research More

ACM Queue Interviews Robert Watson On Open Source Hardware and Research

Comments Filter:

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

  • Hardware support for more sandboxes (Score:1)

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

    • 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

      • 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 (Score:4, Interesting)

        by TheRaven64 ( 641858 ) on Sunday October 21, 2012 @07:44AM (#41720881) Journal

        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.

        • fascinating.
        • 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?
          • 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.

    • 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 term

      • 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? (Score:1, Interesting)

    by 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 discussi

    • All the people of value were at the party last night, you didn't get the invite?
    • 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 [slashdot.org] article also onl

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

    Compiler comes before OS in that hierarchy.

    • 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 apparen

  • Sandbox performance (Score:3)

    by baffled ( 1034554 ) on Saturday October 20, 2012 @01:22PM (#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.

  • 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!"

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

  • I misread the story headline as an interview with *IBM*s Watson.
  • Sadly, it's a link to video, just like the Turing Award Lectures have been for recent awards, e.g. Barbara Liskov in 2008 [acm.org] link to video: http://amturing.acm.org/vp/liskov_1108679.cfm [acm.org]

    .

    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, would

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close