6 ms·

> The only way such an effort can ever hope to succeed is a) an extremely clear standard with a rigorous conformance test VMCALL is too flexible for being abl

by zvrba 9y ago

> The only way such an effort can ever hope to succeed is a) an extremely clear standard with a rigorous conformance test VMCALL is too flexible for being able to call it a "standard". What does the original article suggest? Yeah, define a struct and pass a pointer to it. As "standard" as defining protobuf messages. Heck, even the "big" (Xen, HyperV, VMWare, VirtualBox) hypervisors don't agree on their hypercalls. The problem of having multiple incompatible OS-interfaces is repeating itself, just one level below, on the hypervisor level. Madness. Ironically, these problems would not exist had the world gone the way of IDL and microkernels. > b) a way to run legacy programs that don't comply with the standard No-go unless the VM implements all of the stuff that you want to get rid of. Plus, whatever you decide to run in a VM may want to talk to a service in another VM. How do they talk to each other? [continue the exercise until you reimplement one or more of existing IPC mechanisms].

lmm 9y ago
> Ironically, these problems would not exist had the world gone the way of IDL and microkernels. I see it as another path to a very similar end state. A unikernel running under a hypervisor is much like a process running under a microkernel. > No-go unless the VM implements all of the stuff that you want to get rid of. Legacy components can run under a traditional linux VM running under the same hypervisor. If you've got, say, a gnarly image processing piece that needs to talk to a task queue over unix domain sockets or something, you run them both in the same VM; you can get on with your business, but at the same time that doesn't impact the isolation of your other components, performance/scalability cost is only borne by the component that's causing it, so there's an adequate incentive to properly isolate that component (or maybe not - if it's not causing reliability or performance issues it can stay as it is, that's fine too). > Plus, whatever you decide to run in a VM may want to talk to a service in another VM. How do they talk to each other? In a way that's always traditionally been used for untrusted communications (e.g. network sockets), so that they know not to trust each other.
- zvrba 9y ago
  > In a way that's always traditionally been used for untrusted communications (e.g. network sockets), so that they know not to trust each other. So your "trusted" components now incorporate a TCP/IP or another network stack. Plus you'll somehow have to authenticate the other end...
  - lmm 9y ago
    The network stack shouldn't need to be trusted - inter-unikernel routing can be done by another (untrusted) dedicated unikernel, just as in a microkernel. And yes, whenever one component talks to another they have to authenticate themselves; that's much of the point.
    - zvrba 9y ago
      > inter-unikernel routing can be done by another (untrusted) dedicated unikernel If the routing unikernel is untrusted, how are you going to prevent another unikernel to impersonate it and route on behalf of it? > And yes, whenever one component talks to another they have to authenticate themselves; that's much of the point. So... separate processes running under different users + unix or TCP sockets + user-based firewall rules does the thing?
      - lmm 9y ago
        > If the routing unikernel is untrusted, how are you going to prevent another unikernel to impersonate it and route on behalf of it? If an attacker compromises it the worst they can do is block messages causing a DoS. > So... separate processes running under different users + unix or TCP sockets + user-based firewall rules does the thing? Yes except that with that approach you still have all the other ways those processes could interfere with each other.
        zvrba 9y ago
        > Yes except that with that approach you still have all the other ways those processes could interfere with each other. Yes, you're right, add to that seccomp: http://man7.org/linux/man-pages/man2/seccomp.2.html http://man7.org/linux/man-pages/man2/seccomp.2.html

by zvrba 9y ago

lmm 9y ago

> Ironically, these problems would not exist had the world gone the way of IDL and microkernels. I see it as another path to a very similar end state. A unikernel running under a hypervisor is much like a process running under a microkernel. > No-go unless the VM implements all of the stuff that you want to get rid of. Legacy components can run under a traditional linux VM running under the same hypervisor. If you've got, say, a gnarly image processing piece that needs to talk to a task queue over unix domain sockets or something, you run them both in the same VM; you can get on with your business, but at the same time that doesn't impact the isolation of your other components, performance/scalability cost is only borne by the component that's causing it, so there's an adequate incentive to properly isolate that component (or maybe not - if it's not causing reliability or performance issues it can stay as it is, that's fine too). > Plus, whatever you decide to run in a VM may want to talk to a service in another VM. How do they talk to each other? In a way that's always traditionally been used for untrusted communications (e.g. network sockets), so that they know not to trust each other.

zvrba 9y ago
> In a way that's always traditionally been used for untrusted communications (e.g. network sockets), so that they know not to trust each other. So your "trusted" components now incorporate a TCP/IP or another network stack. Plus you'll somehow have to authenticate the other end...
- lmm 9y ago
  The network stack shouldn't need to be trusted - inter-unikernel routing can be done by another (untrusted) dedicated unikernel, just as in a microkernel. And yes, whenever one component talks to another they have to authenticate themselves; that's much of the point.
  - zvrba 9y ago
    > inter-unikernel routing can be done by another (untrusted) dedicated unikernel If the routing unikernel is untrusted, how are you going to prevent another unikernel to impersonate it and route on behalf of it? > And yes, whenever one component talks to another they have to authenticate themselves; that's much of the point. So... separate processes running under different users + unix or TCP sockets + user-based firewall rules does the thing?
    - lmm 9y ago
      > If the routing unikernel is untrusted, how are you going to prevent another unikernel to impersonate it and route on behalf of it? If an attacker compromises it the worst they can do is block messages causing a DoS. > So... separate processes running under different users + unix or TCP sockets + user-based firewall rules does the thing? Yes except that with that approach you still have all the other ways those processes could interfere with each other.
      - zvrba 9y ago
        > Yes except that with that approach you still have all the other ways those processes could interfere with each other. Yes, you're right, add to that seccomp: http://man7.org/linux/man-pages/man2/seccomp.2.html http://man7.org/linux/man-pages/man2/seccomp.2.html