Live data from Hacker News

IncludeOS – A minimal, resource efficient unikernel for cloud services

includeos.org

51–60 of 85 posts

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#51

I have never really got unikernels, maybe someone could educate me? - There is the argument of reduced attack surface/typechecked safety. I get that, but I don't see how this is different from compiling custom Linux/NetBSD kernels per VM? - There is the argument for increased performance. I don't get that at all -- I've done experiments on unikernel system for MirageOS vs IncludeOS vs Kernel on a web and memcache ser…

I am a kernel developer working on IncludeOS. Take everything I say with a grain of salt as this is just my thoughts at 9 in the morning in written form. 1. I can build a bootable binary without the full TCP and UDP, shaving off 60% of the whole IP stack. LTO removes a large amount of code as well. It makes all the difference. 2. Performance comes from building a fixed binary (all memory addresses are constant), as w…

> Performance comes from building a fixed binary (all memory addresses are constant),

So, no (K)ASLR?

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#52
post #48

Earlier quoted context omitted.

fork() requires support for multiple processes. IncludeOS only has one process, so a fork() doesn't make sense there. Also, I should point out that relying on fork/exec to clean up long running processes sound like something of a hack. Would you really like to have a system that is required to restart itself ever to often as a strategy to manage memory? We've just spent quite a bit of time implementing a buddy alloca…

I don't agree multiple processes are hackish at all. CPUs/MMUs have dedicated hardware for managing memory, O/Ss have tools to limit and monitor memory usage, and separate memory regions/segments can be very effective and simple means for security isolation (save for meltdown/rowhammer-style attacks). I know this could be used as a general argument against any innovation, but single-process-per-requests have worked w…

You present good points, but with IncludeOS you can simply liveupdate it to itself in a few milliseconds to get a pristine heap, and perhaps a few fixes as well. Won't count as downtime.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#54
post #51

Earlier quoted context omitted.

I am a kernel developer working on IncludeOS. Take everything I say with a grain of salt as this is just my thoughts at 9 in the morning in written form. 1. I can build a bootable binary without the full TCP and UDP, shaving off 60% of the whole IP stack. LTO removes a large amount of code as well. It makes all the difference. 2. Performance comes from building a fixed binary (all memory addresses are constant), as w…

> Performance comes from building a fixed binary (all memory addresses are constant), So, no (K)ASLR?

Yes and no, if you really want it there is no reason you can't have it. I know that some OSes now do some link-stage procedures at boot, but we don't. Unikernels seldom need to reboot, and if they do, you might as well update it while preserving all the important bits (including TCP connections) by doing a live update. It's not exactly a simple solution as now you suddenly need a management solution. We also have the management part, but it's not a part of the open-source OS.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#55

I have never really got unikernels, maybe someone could educate me? - There is the argument of reduced attack surface/typechecked safety. I get that, but I don't see how this is different from compiling custom Linux/NetBSD kernels per VM? - There is the argument for increased performance. I don't get that at all -- I've done experiments on unikernel system for MirageOS vs IncludeOS vs Kernel on a web and memcache ser…

I am a kernel developer working on IncludeOS. Take everything I say with a grain of salt as this is just my thoughts at 9 in the morning in written form. 1. I can build a bootable binary without the full TCP and UDP, shaving off 60% of the whole IP stack. LTO removes a large amount of code as well. It makes all the difference. 2. Performance comes from building a fixed binary (all memory addresses are constant), as w…

So how can you build a parallel application on top of this that can share all cores of the CPU?

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#56
post #55

Earlier quoted context omitted.

I am a kernel developer working on IncludeOS. Take everything I say with a grain of salt as this is just my thoughts at 9 in the morning in written form. 1. I can build a bootable binary without the full TCP and UDP, shaving off 60% of the whole IP stack. LTO removes a large amount of code as well. It makes all the difference. 2. Performance comes from building a fixed binary (all memory addresses are constant), as w…

So how can you build a parallel application on top of this that can share all cores of the CPU?

I wrote an SMP API once, and while its fully implemented still in the OS, it won't work right because we changed C API to MUSL and it enables/disables locks internally by counting up/down number of threads. So, that means you cant use it at the moment.

It looks like this: https://github.com/hioa-cs/IncludeOS/blob/dev/api/smp

With that you can schedule work to CPUs directly.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#57
post #23
post #8

Earlier quoted context omitted.

Unikernel Systems, which is cool because it is OCaml based. Their stuff is open source too: https://mirage.io

What I would love more than really any other tech improvement would be a “trusted” mirageos hardware/software environment which would remotely attest to its integrity and the degree of hardware protection it gave running programs. Ie a regular dedicated server, a VM, or a HSM attested to by some authority.

It sounds like you'd like Intel SGX. However, it seems Intel botched the implementation and their SGX VMs are leaking data through a number of attack vectors.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#58
post #29

OSv is another, compatible with some unix apps http://osv.io

It seemed interesting back then but it's kind of dead since the core developers (Avi Kivity, Nadav Har'El and others) have moved on to another startup called ScyllaDB that is a re-implementation of Apache Cassandra in C++.

The OSv project is indeed now moving much slower than it used to when we had an entire startup company devoted to it, but is not dead - it still has three committers from three companies - myself (Nadav Har'El), Waldek Kozaczuk and Timmons Player. It still works, and you are welcome to try it. OSv is not as minimal as includeOS, which of course depending on your viewpoint and use case, is either a pro or a con. OSv supports more types of hypervisors, and has support for a larger subset of the Linux ABI, can run pre-compiled, unmodified, Linux shared libraries, and supports multi-core VMs.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#59
post #48

Earlier quoted context omitted.

fork() requires support for multiple processes. IncludeOS only has one process, so a fork() doesn't make sense there. Also, I should point out that relying on fork/exec to clean up long running processes sound like something of a hack. Would you really like to have a system that is required to restart itself ever to often as a strategy to manage memory? We've just spent quite a bit of time implementing a buddy alloca…

I don't agree multiple processes are hackish at all. CPUs/MMUs have dedicated hardware for managing memory, O/Ss have tools to limit and monitor memory usage, and separate memory regions/segments can be very effective and simple means for security isolation (save for meltdown/rowhammer-style attacks). I know this could be used as a general argument against any innovation, but single-process-per-requests have worked w…

I'm not saying multiple processes are a hack, just relying on fork/exec to clean up memory. Safeguarding against memory fragmentation is imho a solved problem - or at least solvable if you apply known methods.

Other than that I think you are right. Unless IncludeOS can prove that it can offer something akin to the same level of convenience as current Linux-based systems have I think it'll be hard for the OS to get traction.

The upside would be stronger isolation and a system that would be a lot harder to break into. The absence of system calls makes most attacks very, very inconvenient and the absence of self-modification functionality is strengthening it further.

Re: IncludeOS – A minimal, resource efficient unikernel for cloud services

#60
post #14

Do these unikernel OSs tend to be language specific? Like if this app is written in x language, use y OS?

Some do, and some don't. OSv (https://github.com/cloudius-systems/osv), for example, is also a unikernel in the sense that it can only run a single application at a time (it has no kernel-user boundary, nor support for multiple isolated processes). But is designed to run any Linux executables (using a dynamic linker which is part of the kernel) so it is not limited to a particular programming language.
Post reply on HN