4 ms·
There are generally three kinds of these systems. 1) FWK (full weight kernel) a stripped-down version of a full featured kernel only having the things needed t
by externalreality 8y ago
There are generally three kinds of these systems.
1) FWK (full weight kernel) a stripped-down version of a full featured kernel only having the things needed to run a particular application. Remember as the upstream kernel progresses you have to some how find a way to update your modified kernel to keep up with security fixes and all.
2) A LWK (light weight kernel) a small kernel built from scratch that is added as a library to an application (it will likely be incompatible with many existing applications built for other systems) - a pro is that system updates are practically non-existent. You don't have to rebuild your image with Debian patches or anything like that since the kernel is minimal and unique. And exploits have minimal impact in any case.
3) Then there is the hybrid approach where you have a LWK that runs along side a FWK with the light weight kernel handling most of the system calls while the full weight kernel (e.g Linux) handles system calls for compatibility. A multi-kernel approach.
I have no idea what route Nanos takes since I can't see the code and its not mentioned anywhere. Keep in mind a Unikernel is usually a single address space kind of thing, so you shouldn't be able to fork or exec. Since Ops permits arbitrary Go/C/C++/Ruby programs I wonder what happens if you try to exec something.
In any case these systems are more secure than containers because an exploit in the code running in the container can affect the host kernel (There is no real isolation). With Unikernels, in some cases, the system will actually unplug cores from the host kernel and boot the Unikernels on those cores utilizing available NUMA features of the CPU. This allows for more isolation and the kernel itself is minimal so it has small attack surface and, in some cases, added performance characteristics.
There are good debugging tools these days for libOS's (Unikernels) and they date back all the way to MIT's exokernel design and even further back. They have caught traction recently because:
1) They are easy to make (You are either stripping down a working kernel or building a very small one - think smaller than minix3).
2) Cloud computing (security) and HPC (performance on commodity) make them relevant again.
3) Not to mention they are fundamentally a better technology than containers, IMHO there is no debate, containers will be replaced by libos(s)/unikernels.
- muricula 8y ago"You don't have to rebuild your image with Debian patches or anything like that since the kernel is minimal and unique. And exploits have minimal impact in any case." This isn't correct. If there is a bug in the unikernel library you are building into your unikernel you can still exploit it. Imagine if there is a DHCP parsing error in the networking stack which can lead to Remote Code Execution. Or imagine if there's a deserialization error in a web framework which can lead to remote code execution (RCE). Or In both cases you need to follow the upstream and rebuild the unikernel. Additionally, I think that unikernels are less secure if anything. If you break into the application you are already in kernel mode and can access any file or privilege resources belonging to the unikernel. Also, there is no hope for defense in depth techniques like sandboxing or resource brokers. With a normal application you would need to do some sort of privilege escalation or sandbox escape after hacking the application.
- externalreality 8y agoThe kernel is small so security patches and such will be less frequent and there are minimal utilities like ssh, shell, what have you. Also, the key is that there is very little to exploit so the likely hood of it being exploited is reduced.
- muricula 8y agoI'm all for attack surface reduction, but little to exploit is not nothing to exploit. Your shell, sshd, and networking stack have probably all been exploited many times.
- externalreality 8y ago> Your shell, sshd, and networking stack have probably all been exploited many times. Yes, I've exploited them myself with script-kiddy tools. Its not hard. Remember those your average libos application may not have any of those things (if not only an simple IP stack).
- gdy 8y ago"can access any file or privilege resources belonging to the unikernel" What resources?
- rhinoceraptor 8y agoI really doubt unikernels will ever be more than a fad. Hardware isn't a good abstraction layer, because 99% of developers aren't kernel developers. And sure, a kernel's containment mechanism is subject to exploits. But so are hypervisors. At least if you exploit an application in a (properly made) container, you're just an unprivileged user inside the container. You're not root, in the container or out. If you exploit a unikernel application, you can directly go and target the hypervisor.
- externalreality 8y ago> because 99% of developers aren't kernel developers That is like saying you have to be a kernel developer to work with containers.