← Back to context

Comment by anttiok

10 years ago

The point of rump kernels is not leveraging the whole stack from $OS. It's leveraging the unmodified drivers from $OS without the wholesale import of policies from $OS.

Sure, driver kits are an old idea, but starting from OSKit in the 90's the common fault is that the kits are forks over upstream. Forking is easy, but forking means that maintenance is unbearable unless you happen to be an organization with person-years to spare just to keep up with bugfixes and new features from upstream. Figuring out how to do it without forking (i.e. anykernel architecture which enables rump kernels out-of-the-box) takes more effort, but wins long-term. "proof": DDE is for Linux 2.4/2.6 drivers. NetBSD source tree from a second ago gives you rump kernels.

9 comments

anttiok

Reply
nickpsecurity  10 years ago

Exactly. It's an evolution of the old stuff and OSkit deserves credit too. Now, just imagine if the concept was discovered and built on sooner. Same with DDE. We'd have more projects doing more stuff. Took a while for one, bright outlier to make some of that potential happen. That's the problem I was illustrating. I like what's going on in Rump Kernel space, though.

  • anttiok  10 years ago

    Not to downplay the prior art, but I'm not sure I can call rump kernels an evolution of the previous work. I certainly hadn't heard about OSKit at least in 2009 (since it's not cited in my 2009 USENIX paper), despite going through several rejections with program committees for rump kernels since 2007. I first heard about DDEKit at my FOSDEM 2011 presentation when someone asked about the differences between rump kernels and DDEKit. I don't know if me being ignorant is more embarrassing for myself or the general computing community.

    I do know that even my first [rejected] paper on rump kernels from 2007 stressed the idea of not forking. Of course, I was young and stupid(er) back then and didn't realize that academic program committees couldn't care less about if something actually worked or not, as long as you could generate nice graphs out of it.

    Yes, I absolutely believe that drivers should be separate from the OS layer. Them being bundled together is a (pre)historic mistake. I agree that we would be in a much better place if projects like OSKit and DDEKit had gotten attention early on.

    • nickpsecurity  10 years ago

      "cited in my 2009 USENIX paper"

      Oh hell: didn't realize I was talking to the inventor himself. Pleasant surprise. My poor memory might be getting mixed up here on timeline. Huge dissertation people kept giving me was 2012: didn't realize you were trying to push this stuff far back as 2007. You may have been a bit ahead of some & problem I describe was working in reverse: your info not getting to them. ;) Additionally, DDE was the newer effort. The old one I tried to remember was this:

      https://www.usenix.org/legacy/event/osdi04/tech/full_papers/...

      This is the bell that rang in my ear when people were first telling me about how Rump Kernels let you reuse drivers. By 2006, a German paper at Dresden had similarly reused FreeBSD drivers for disks or something. The same team continued working to build all kinds of L4 stuff and I/O virtualization, resulting in DDE around 2010-2011 range. An advantage of DDE, which yours might have too (dissertation on my backlog), is that you can use just components needed for your driver's needs. OKL4 used such tech in their "microvisor" platform with these results: native drivers on L4 kernel for minimal or security-focused deployment; minimal, device wrapper for Linux drivers for effeciency; use of drivers in a full VM; virtual stubs to any of this for clients. So, depending on the When, the What of your work might have benefited from any lessons learned during these projects or even communications with group members. If their existence/accomplishments had reached you.

      So, that's what was in my head. May have helped, may have not. Rather than evolution, your work sounds like independent re-invention of one capability and new invention in others. That happens, too, even in my own investigations. I got more confused as I just looked at the 2009 paper as it talks about a lot more than driver reuse. I was going to drop your example from my meme (or reverse it) but I might need to straight up read your book before I talk about the subject more. I think what a lot of people describe to me online about Rump Kernels and what your paper says are a bit different. Misinformation could've thrown off my opinion.

      "I do know that even my first [rejected] paper on rump kernels from 2007 stressed the idea of not forking."

      That's a key advantage of your work and worth several different lines of research. Whether academics like it or not, it was a good idea. Good job focusing on that hard problem as few even tried.

      " I don't know if me being ignorant is more embarrassing for myself or the general computing community."

      It could be you or them, as I've written, but my meme about leveraging prior work is not about you being ignorant: it's how our field tracks and leverages what we've learned. I know people think of what I think before me so I searched "re-use device drivers" back when idea came to me. Gave me 2004 paper. Many papers I've found have great "related work" sections with references that teach me plenty. Some were clearly a quick Google and summary that don't reflect field's accomplishments. So, culture of institution plays into it. Past that, the stuff is so spread out in so many Universities, conferences, ACM/IEEE, web articles, DEFCON's, etc it's nearly impossible to track it all unless one is obsessively dedicated like myself. ;) But the tradeoff was that I couldn't be implementing in code as many of my ideas like you did, eh?

      So, I think the issue here is that good ideas were brewing in several different places yet without a way to connect them and academia as a whole not really pushing for that. I keep trying to determine a solution but it's tricky. Recurring concept is to have a non-profit collection (eg Citeseerx) of most of the stuff with tags (eg "driver re-use") and good search functionality to encourage serendipity. Plus, a series of forums that only allow people doing research, coding things, other proven capabilities, or referrals by the same. Then, you see someone's work, you can contact them directly or start a forum post related to their work that notifies them. Encourage conversations that work out hard problems or prevent wasteful re-work. Public can read them but not comment unless approved by moderation as useful. Goal is to keep quality at pro or aspiring pro level. Tricky to get this going, for sure, but I'm trying to work out the concept itself before worrying about popularity too much. Thoughts on this scheme or others?

      "Yes, I absolutely believe that drivers should be separate from the OS layer. Them being bundled together is a (pre)historic mistake. I agree that we would be in a much better place if projects like OSKit and DDEKit had gotten attention early on."

      Basically my point. Again, not a gripe at you or Rump kernels: just how stuff stays obscure. Your original papers actually fit into that category now that we've talked about them. Least yours got out there and took off. Great work on both the tech and making it a success. :)

      4 replies →