5 ms·

Very. Back here in reality, we care about performance so much that we do not even close TCP connections needlessly. So we can support thousands of requests per

Very. Back here in reality, we care about performance so much that we do not even close TCP connections needlessly. So we can support thousands of requests per second, not just... one per three seconds? I can find few better way of discrediting unikernels than to claim this as their killer feature. (The actual killer feature being their ability to reduce attack surface substantially by simply having fewer syscalls that can be abused.)

eyberg 7y ago
I'm not advocating every application should do this as evidenced that this is a toggable switch that's off by default and even by itself doesn't actually have this particular feature (I was forcibly stopping the app through the inline instructions.). Just that it can be done is a capability that some people are very interested in. There is a category of security products called 'moving target defense' that this capability fits into. As for the syscall/security argument I find that to be one of the weakest security arguments for unikernels. Fewer syscalls unfortunately leads to a much smaller set of applications that can be ran. Even trivial hello world style of apps can use north of 30-40 different types of syscalls. Not saying you should keep adding more but spending time trying to reduce what's there is kind of a non-starter if you want adoption.
- orf 7y ago
  > Even trivial hello world style of apps can use north of 30-40 different types of syscalls I'd wager a lot of those are irrelevant in a unikernel world. Some of those might be dealing with ttys, or setting terminal attributes, or other needless things.
  - eyberg 7y ago
    you're absolutely correct - in cases like that they become nops, however, if you don't have at least stubs you can't load unmodified software which imo is a imperative for any type of mass adoption Drew DeVault had a recent blogpost on this very subject -> https://drewdevault.com/2020/01/04/Slow.html https://drewdevault.com/2020/01/04/Slow.html however, when we were adding support for various language runtimes I was surprised at how much (ab)use there was where certain calls were used in a very very different manner than what was intended - for instance one might wonder why we have limited pipe support if we don't have the notion of multiple processes - cause ruby uses it to communicate from the main vm thread to the user thread - it's little gems like this that you simply won't know until you try to support it then there's the cases where you might support one type of syscall but there's another syscall exactly like it except it has one additional argument
    - sitkack 7y ago
      I could see a lazy libc that elides syscalls until later in the evolution of a program so that the perf hit isn't paid until it is actually needed. Especially if you can detect when the program is finished, so the cleanup code can be skipped, destroying the entire execution environment. `fast_exit(42)`
didroe 7y ago
>The actual killer feature being their ability to reduce attack surface substantially by simply having fewer syscalls that can be abused Can you not use Seccomp for that?

eyberg 7y ago

I'm not advocating every application should do this as evidenced that this is a toggable switch that's off by default and even by itself doesn't actually have this particular feature (I was forcibly stopping the app through the inline instructions.). Just that it can be done is a capability that some people are very interested in. There is a category of security products called 'moving target defense' that this capability fits into. As for the syscall/security argument I find that to be one of the weakest security arguments for unikernels. Fewer syscalls unfortunately leads to a much smaller set of applications that can be ran. Even trivial hello world style of apps can use north of 30-40 different types of syscalls. Not saying you should keep adding more but spending time trying to reduce what's there is kind of a non-starter if you want adoption.

orf 7y ago
> Even trivial hello world style of apps can use north of 30-40 different types of syscalls I'd wager a lot of those are irrelevant in a unikernel world. Some of those might be dealing with ttys, or setting terminal attributes, or other needless things.
- eyberg 7y ago
  you're absolutely correct - in cases like that they become nops, however, if you don't have at least stubs you can't load unmodified software which imo is a imperative for any type of mass adoption Drew DeVault had a recent blogpost on this very subject -> https://drewdevault.com/2020/01/04/Slow.html https://drewdevault.com/2020/01/04/Slow.html however, when we were adding support for various language runtimes I was surprised at how much (ab)use there was where certain calls were used in a very very different manner than what was intended - for instance one might wonder why we have limited pipe support if we don't have the notion of multiple processes - cause ruby uses it to communicate from the main vm thread to the user thread - it's little gems like this that you simply won't know until you try to support it then there's the cases where you might support one type of syscall but there's another syscall exactly like it except it has one additional argument
  - sitkack 7y ago
    I could see a lazy libc that elides syscalls until later in the evolution of a program so that the perf hit isn't paid until it is actually needed. Especially if you can detect when the program is finished, so the cleanup code can be skipped, destroying the entire execution environment. `fast_exit(42)`

didroe 7y ago

>The actual killer feature being their ability to reduce attack surface substantially by simply having fewer syscalls that can be abused Can you not use Seccomp for that?