4 ms·

Cross Region Unikernels at the Edge

21 points by eyberg 4y ago

Ericson2314 4y ago
This is marketing fluff. A piece on what their nanos is nicer. It is not a real unikernel as there is still a kernel program boundary. It could still be interesting, however.
- eyberg 4y ago
  We separate user/kernel because if you don't it is trivial to change the page permissions of anything and that's game over. It is important to note that different context switches have different costs some of which we have removed. It isn't just one thing. A hundred different processes running on 1 vcpu has a huge perf cost.
  - rwmj 4y ago
    Usually the trust boundary is outside the unikernel (eg. it's running in a VM) so changing the page tables doesn't matter. In fact it can be an advantage - for example it can be used to make more efficient garbage collectors.
    - eyberg 4y ago
      Definitely aware of the advantages but from our perspective and end-user use-cases being able to flip the U/S or R/w bits allows an attacker to overwrite the memory in question in which they can supply their own code.
  - chc4 4y ago
    One of the entire points of a unikernel is that you don't have to do a TLB flush on context switch, which especially post-Meltdown is very expensive...because you never change your page table or have context switches! Having a seperate kernel memory map gets rid of that entirely.
    - eyberg 4y ago
      For a kernel<>user yes, however you don't do the TLB flush for every type of switch. For instance thread<>thread you wouldn't and if you are single process there is no process<>process switch which is very expensive. It is still possible to get much greater performance this way without having to cut corners. We routinely benchmark applications such as go/rust performing significantly better because of this. As for needing to change page tables - you need to deal with that regardless. To dig deeper there is an awful lot going on in say linux to deal with the fact that you have many different programs and (users) running on the same system. Whether it is shared memory or the scheduler itself - there is a ton of work that goes into that and by explicitly not supporting that you can make lots of gains. I don't think we are trying to promote a purist approach to this - we're trying to be pragmatic.
  - Ericson2314 4y ago
    I'm not saying it's bad idea. I'm just saying that makes it something other than a unikernel. Call it a duokernel?

21 points by eyberg 4y ago

This is marketing fluff. A piece on what their nanos is nicer. It is not a real unikernel as there is still a kernel program boundary. It could still be interesting, however.

eyberg 4y ago
We separate user/kernel because if you don't it is trivial to change the page permissions of anything and that's game over. It is important to note that different context switches have different costs some of which we have removed. It isn't just one thing. A hundred different processes running on 1 vcpu has a huge perf cost.
- rwmj 4y ago
  Usually the trust boundary is outside the unikernel (eg. it's running in a VM) so changing the page tables doesn't matter. In fact it can be an advantage - for example it can be used to make more efficient garbage collectors.
  - eyberg 4y ago
    Definitely aware of the advantages but from our perspective and end-user use-cases being able to flip the U/S or R/w bits allows an attacker to overwrite the memory in question in which they can supply their own code.
- chc4 4y ago
  One of the entire points of a unikernel is that you don't have to do a TLB flush on context switch, which especially post-Meltdown is very expensive...because you never change your page table or have context switches! Having a seperate kernel memory map gets rid of that entirely.
  - eyberg 4y ago
    For a kernel<>user yes, however you don't do the TLB flush for every type of switch. For instance thread<>thread you wouldn't and if you are single process there is no process<>process switch which is very expensive. It is still possible to get much greater performance this way without having to cut corners. We routinely benchmark applications such as go/rust performing significantly better because of this. As for needing to change page tables - you need to deal with that regardless. To dig deeper there is an awful lot going on in say linux to deal with the fact that you have many different programs and (users) running on the same system. Whether it is shared memory or the scheduler itself - there is a ton of work that goes into that and by explicitly not supporting that you can make lots of gains. I don't think we are trying to promote a purist approach to this - we're trying to be pragmatic.
- Ericson2314 4y ago
  I'm not saying it's bad idea. I'm just saying that makes it something other than a unikernel. Call it a duokernel?