3 ms·

The key thing to realize, I think, is that if you're using virtualization, a unikernel is nothing more than a process that uses a very strange system call API.

by ori_b 11y ago

rwmj 11y ago
In particular one where you get a fixed amount of memory and it's very hard to allocate any more.
- _wmd 11y ago
  I can't help but respond to each of these incredibly myopic comments that suggest some deficiency with unikernels that doesn't already exist with a traditional OS: this exact same problem exists on Linux, except there you have multiple layers of allocators managing the fixed 'heap' available. There's no reason few allocators can't cope as well, or why Mirage couldn't implement support for memory ballooning like Linux does, or etc. etc.
  - rwmj 11y ago
    Except the OP is talking about how running a Unikernel on qemu is basically the same as running a process on the host, except with a strange system call API (and one which might even be more complex than the real API). So talking about how ballooning or RAM hotplugging is clunky is very relevant indeed here.
lmm 11y ago
Sure. Unikernels are just a way to a) use an extremely restricted system call API to enforce separation between processes b) have my processes be VMs for memory-safe languages for safety c) not implement a user/kernel mode distinction within a single application because it's just overhead at that point.
- ori_b 11y ago
  > a) use an extremely restricted system call API to enforce separation between processes b) have my processes be VMs for memory-safe languages for safety c) not implement a user/kernel mode distinction within a single application because it's just overhead at that point. But the second two points are already covered by just writing an application and not running it in a virtual machine. Remember, your VMs are already running on an OS. And the first -- I'm not convinced that qemu and x86 is all that much more restricted than a well jailed process. Given the complexity of the PC, and the number of critical Xen/KVM/... vulnerabilities, it certainly isn't trivial to emulate securely. Note, there is one advantage to unikernels, and that's lower overhead access to network hardware than you get with the socket API. This advantage is also available with netmap.
  - lmm 11y ago
    > And the first -- I'm not convinced that qemu and x86 is all that much more restricted than a well jailed process. Given the complexity of the PC, and the number of critical Xen/KVM/... vulnerabilities, it certainly isn't trivial to emulate securely. Xen has their own priorities and I have my views on their code quality. The interface is that much smaller that it should be much more possible to implement securely than the unix API (which isn't even well-defined). People elsewhere are talking about seL4; I hope we'll one day see a formally verified hypervisor. I don't think we'll ever see a formally verified unix container. In the long run you're right, there's ultimately no difference between compiling my OCaml to a binary that runs on a secure formally verified microkernel and building it into a unikernel that runs on a secure formally verified hypervisor. But I can take steps towards the latter now - I can deploy unikernel systems to EC2 today, and while they may not be more secure than deploying processes to Joyent today, they're using an interface that should make it possible to run them on a more secure environment.
    - rwmj 11y ago
      You can use seccomp to reduce the scope of the Linux system call API. I think the real point here is that AWS exists, and so virtualization is the new baremetal, but the advantage over baremetal is the range of "hardware" is much more limited. You have virtio / XenPV disks, not twenty different SCSI devices you need to write drivers for and debug. Therefore writing interesting kernels directly to the virt layer and running those in the cloud makes sense.
u320 11y ago
Yep. Which also means that whatever advantages they bring, we can probably get in a traditional system call API if designed the right way. There was a highly interesting research project along these lines: https://arrakis.cs.washington.edu/ https://arrakis.cs.washington.edu/ The Arrakis paper also show how much overhead the traditional UNIX architecture is (contrary to the authors assertions) for many popular workloads. It is now merged back into the project it was forked from (Barrelfish) which in itself is a very interesting research project. Well worth studying for those that don't believe UNIX is the last word in OS design.

The key thing to realize, I think, is that if you're using virtualization, a unikernel is nothing more than a process that uses a very strange system call API.

by ori_b 11y ago

The key thing to realize, I think, is that if you're using virtualization, a unikernel is nothing more than a process that uses a very strange system call API.

rwmj 11y ago

In particular one where you get a fixed amount of memory and it's very hard to allocate any more.

_wmd 11y ago
I can't help but respond to each of these incredibly myopic comments that suggest some deficiency with unikernels that doesn't already exist with a traditional OS: this exact same problem exists on Linux, except there you have multiple layers of allocators managing the fixed 'heap' available. There's no reason few allocators can't cope as well, or why Mirage couldn't implement support for memory ballooning like Linux does, or etc. etc.
- rwmj 11y ago
  Except the OP is talking about how running a Unikernel on qemu is basically the same as running a process on the host, except with a strange system call API (and one which might even be more complex than the real API). So talking about how ballooning or RAM hotplugging is clunky is very relevant indeed here.

lmm 11y ago

Sure. Unikernels are just a way to a) use an extremely restricted system call API to enforce separation between processes b) have my processes be VMs for memory-safe languages for safety c) not implement a user/kernel mode distinction within a single application because it's just overhead at that point.

ori_b 11y ago
> a) use an extremely restricted system call API to enforce separation between processes b) have my processes be VMs for memory-safe languages for safety c) not implement a user/kernel mode distinction within a single application because it's just overhead at that point. But the second two points are already covered by just writing an application and not running it in a virtual machine. Remember, your VMs are already running on an OS. And the first -- I'm not convinced that qemu and x86 is all that much more restricted than a well jailed process. Given the complexity of the PC, and the number of critical Xen/KVM/... vulnerabilities, it certainly isn't trivial to emulate securely. Note, there is one advantage to unikernels, and that's lower overhead access to network hardware than you get with the socket API. This advantage is also available with netmap.
- lmm 11y ago
  > And the first -- I'm not convinced that qemu and x86 is all that much more restricted than a well jailed process. Given the complexity of the PC, and the number of critical Xen/KVM/... vulnerabilities, it certainly isn't trivial to emulate securely. Xen has their own priorities and I have my views on their code quality. The interface is that much smaller that it should be much more possible to implement securely than the unix API (which isn't even well-defined). People elsewhere are talking about seL4; I hope we'll one day see a formally verified hypervisor. I don't think we'll ever see a formally verified unix container. In the long run you're right, there's ultimately no difference between compiling my OCaml to a binary that runs on a secure formally verified microkernel and building it into a unikernel that runs on a secure formally verified hypervisor. But I can take steps towards the latter now - I can deploy unikernel systems to EC2 today, and while they may not be more secure than deploying processes to Joyent today, they're using an interface that should make it possible to run them on a more secure environment.
  - rwmj 11y ago
    You can use seccomp to reduce the scope of the Linux system call API. I think the real point here is that AWS exists, and so virtualization is the new baremetal, but the advantage over baremetal is the range of "hardware" is much more limited. You have virtio / XenPV disks, not twenty different SCSI devices you need to write drivers for and debug. Therefore writing interesting kernels directly to the virt layer and running those in the cloud makes sense.

u320 11y ago

Yep. Which also means that whatever advantages they bring, we can probably get in a traditional system call API if designed the right way. There was a highly interesting research project along these lines: https://arrakis.cs.washington.edu/ https://arrakis.cs.washington.edu/ The Arrakis paper also show how much overhead the traditional UNIX architecture is (contrary to the authors assertions) for many popular workloads. It is now merged back into the project it was forked from (Barrelfish) which in itself is a very interesting research project. Well worth studying for those that don't believe UNIX is the last word in OS design.