4 ms·

Unikernels are cool to play with. Erlang is cool too. But... - [name] is a kernel thread not a user space process. - its libssl, not "libopenss" - installing

by zobzu 11y ago

Unikernels are cool to play with. Erlang is cool too. But... - [name] is a kernel thread not a user space process. - its libssl, not "libopenss" - installing rpc, some obscure 55k listening port, and calling it bloated.. heh so cheap. Once past all this FUD - what does a unikernel (basically the same as running linux and your app as /sbin/init except it's in Erlang and not C here)? - its obscure. you get security mainly because nobody knows what you're running. - its library based. like regular OSes. - it runs only one program. or a million of them, like a regular OS, but with zero separation between them so compromise one means compromise all, actually. Else you have to add the separation layer yourself by writing more apps per "system" and make them communicate. - its undebuggable without a lot of knowledge - 'script kiddies' will run ./erlang-hack-for-x instead of ./rootshell.sh, this changes nothing to that. Remember the XEN exploit a few month ago? That'd still work and give access to all the Erlang instances. Its not that hard. - its not faster, its actually slower, when compared to C kernel+code. - it doesnt compile itself, you need a "regular OS" to deploy it - it uses the same memory space for mostly everything (regular OSes use protected memory per process, its hardware enforced by the CPU) - namespaced linux boots in < 10ms already... There are much better implementations of safer, faster, cleaner OSes with better paradigms that also do away with backward compat and using modern, memory safe languages (http://en.wikipedia.org/wiki/Singularity_%28operating_system%29 http://en.wikipedia.org/wiki/Singularity_%28operating_system... for a well-known one). For the record MS also developed Drawbridge (process+lib, so not exactly a unikernel) because they could not do away with windows compatibility. So yeah. If you have doubts, look at the example code at https://github.com/technolo-g/unikernel-demo https://github.com/technolo-g/unikernel-demo

amirmc 11y ago
What FUD? There appears to be more FUD in your comment than I've seen from any of the unikernel projects. Most of the claims you've made seem to be coming from the existing paradigm of how people write code for the cloud. If you're determined to stay in that mindset, then unikernels will probably not make much sense to you. The whole point is to reevaluate our assumptions about developing for cloud-native environments, which leads to different approaches (many cloud-services are already single-purpose). No-one is claiming that unikernels are some kind of panacea but they are a useful addition to the toolbox. Also, if you really want to compare security and vulnerabilities, then you should consider things like TCB and look at CVEs for both Xen and Linux. The way you describe it is almost disingenuous. The following talks have useful discussion points. https://fosdem.org/2015/schedule/event/zombieapocalypse/ https://fosdem.org/2015/schedule/event/zombieapocalypse/ https://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-_saal_2_-_201412271245_-_trustworthy_secure_modular_operating_system_engineering_-_hannes_-_david_kaloper.html#video https://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-...
- zobzu 11y ago
  If you read the first 3 sentences, 2 are technically completely wrong and the third is a deliberately fake data. That's called FUD. I'm all for the positive attitude stuff - unless the presentations start like that, I then have no sympathy. The linked presentation actually claims unikernels are the panacea, by the way. Have you read it?
pjmlp 11y ago
The problem with Mesa/Cedar, Modula-3/Spin, Modula-2/Lilith, Oberon/Native Oberon, Oberon-2/AOS, Sing#/Singularity and many others is compatibility and lack of buy-in from OS vendors. Personally I see application compartments, wider adoption of Swift, Java, .NET Native, OCaml, Haskell, Go, D, Rust, Erlang, ..., alongside unikernels as the way forward to mainstream adoption. One day we will get C free OS stacks.
- vardump 11y ago
  C/C++ is the language you write the library in, so that it's callable from every other language. Hopefully Rust, Nim (and Golang one day) will be able to produce C-API compatible replacements. API can also be something better than what .so and .dlls provide, as long as everyone is on board. I guess Rust and Nim are the real contenders, as only a language with "zero runtime" is going to cut it.
  - pjmlp 11y ago
    It is an historical accident that C == OS ABI, as mainstream OSes copied UNIX model. This wasn't true in other OSes. Windows is currently moving to COM as the main OS ABI, specially with the WinRT focus. Android also has little support for C ABI, beyond wrapping .so in JNI wrappers. Another example are mainframe systems like OS/400, where the ABI is bytecode based (TIMI).
- zobzu 11y ago
  Yeah exactly Microsoft's point I think. I'm not sure if its the best trade off right now, but it certainly makes sense. It might help bridging the current solutions, hopefully (even thus that will perhaps take 10 years)
pjc50 11y ago
namespaced linux boots in < 10ms already Can someone show me this?
- justincormack 11y ago
  The OP means the creation time of a Linux "container" is less than 10ms, ie the time for the system calls you need to create the namespaces and cgroups. While you can boot a unikernel from nothing in that time.
  - zobzu 11y ago
    Actually, I meant booting! Had to look for it in the HN history, look at this guy's implementation: https://www.youtube.com/watch?v=6SxLvz6pcGs https://www.youtube.com/watch?v=6SxLvz6pcGs ~30ms here, the post indicates some kind of intel NUC (so not exactly the fastest thing) The syscalls themselves are probably sub-millisecond
edwintorok 11y ago
> with zero separation between them the hypervisor separates unikernels from each-other.
- CSDude 11y ago
  I think he means the 'programs' running under same unikernel
erikb 11y ago
The security he means is not because obscurity but because you have less stuff you don't need. At least that's what he means I think.

by zobzu 11y ago

amirmc 11y ago

What FUD? There appears to be more FUD in your comment than I've seen from any of the unikernel projects. Most of the claims you've made seem to be coming from the existing paradigm of how people write code for the cloud. If you're determined to stay in that mindset, then unikernels will probably not make much sense to you. The whole point is to reevaluate our assumptions about developing for cloud-native environments, which leads to different approaches (many cloud-services are already single-purpose). No-one is claiming that unikernels are some kind of panacea but they are a useful addition to the toolbox. Also, if you really want to compare security and vulnerabilities, then you should consider things like TCB and look at CVEs for both Xen and Linux. The way you describe it is almost disingenuous. The following talks have useful discussion points. https://fosdem.org/2015/schedule/event/zombieapocalypse/ https://fosdem.org/2015/schedule/event/zombieapocalypse/ https://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-_saal_2_-_201412271245_-_trustworthy_secure_modular_operating_system_engineering_-_hannes_-_david_kaloper.html#video https://media.ccc.de/browse/congress/2014/31c3_-_6443_-_en_-...

zobzu 11y ago
If you read the first 3 sentences, 2 are technically completely wrong and the third is a deliberately fake data. That's called FUD. I'm all for the positive attitude stuff - unless the presentations start like that, I then have no sympathy. The linked presentation actually claims unikernels are the panacea, by the way. Have you read it?

pjmlp 11y ago

The problem with Mesa/Cedar, Modula-3/Spin, Modula-2/Lilith, Oberon/Native Oberon, Oberon-2/AOS, Sing#/Singularity and many others is compatibility and lack of buy-in from OS vendors. Personally I see application compartments, wider adoption of Swift, Java, .NET Native, OCaml, Haskell, Go, D, Rust, Erlang, ..., alongside unikernels as the way forward to mainstream adoption. One day we will get C free OS stacks.

vardump 11y ago
C/C++ is the language you write the library in, so that it's callable from every other language. Hopefully Rust, Nim (and Golang one day) will be able to produce C-API compatible replacements. API can also be something better than what .so and .dlls provide, as long as everyone is on board. I guess Rust and Nim are the real contenders, as only a language with "zero runtime" is going to cut it.
- pjmlp 11y ago
  It is an historical accident that C == OS ABI, as mainstream OSes copied UNIX model. This wasn't true in other OSes. Windows is currently moving to COM as the main OS ABI, specially with the WinRT focus. Android also has little support for C ABI, beyond wrapping .so in JNI wrappers. Another example are mainframe systems like OS/400, where the ABI is bytecode based (TIMI).
zobzu 11y ago
Yeah exactly Microsoft's point I think. I'm not sure if its the best trade off right now, but it certainly makes sense. It might help bridging the current solutions, hopefully (even thus that will perhaps take 10 years)

pjc50 11y ago

namespaced linux boots in < 10ms already Can someone show me this?

justincormack 11y ago
The OP means the creation time of a Linux "container" is less than 10ms, ie the time for the system calls you need to create the namespaces and cgroups. While you can boot a unikernel from nothing in that time.
- zobzu 11y ago
  Actually, I meant booting! Had to look for it in the HN history, look at this guy's implementation: https://www.youtube.com/watch?v=6SxLvz6pcGs https://www.youtube.com/watch?v=6SxLvz6pcGs ~30ms here, the post indicates some kind of intel NUC (so not exactly the fastest thing) The syscalls themselves are probably sub-millisecond

edwintorok 11y ago

> with zero separation between them the hypervisor separates unikernels from each-other.

CSDude 11y ago
I think he means the 'programs' running under same unikernel

erikb 11y ago

The security he means is not because obscurity but because you have less stuff you don't need. At least that's what he means I think.