7 ms·

> It's a smaller, cleaner, interface that's been designed from day 1 to be secure, Care to argue how something based on sharing memory could ever be more secur

by zvrba 9y ago

> It's a smaller, cleaner, interface that's been designed from day 1 to be secure, Care to argue how something based on sharing memory could ever be more secure than sending messages over pipes or sockets (between different processes)?

jsjohnst 9y ago
I would argue they are roughly comparable, not one better than the other. The risk profile is similar and the common CVEs are the same between the two.
mato 9y ago
Pipes and sockets on a local system are usually implemented using shared memory. While there are challenges to implementing secure* shared memory interfaces, it has been done (see eg. SEL4, QNX and many others). * For example, DoS-safe
- zvrba 9y ago
  > Pipes and sockets on a local system are usually implemented using shared memory. ... where the sharing is mediated by the kernel. You can't access the pipe/socket buffers directly from a user-space program. EDIT: IIRC, POSIX message queues, at least on Solaris, are implemented SHM and clever queue bookkeeping. But MQs are not sockets or pipes.
lmm 9y ago
If there was only one of pipes, sockets, system calls, and the filesystem, that would be fine. Instead there are all of those and more. There's no fundamental reason shared memory should be less safe than sockets (say); ultimately it's just bytes. Shared memory has a bad reputation because of how it behaves when processes sharing memory run concurrently, especially if they're both writing, but that's not a concern when we're talking about a unikernel interacting with the host, because there's no need to have anything happen concurrently there.
- zvrba 9y ago
  > If there was only one of pipes, sockets, system calls, and the filesystem, that would be fine. Instead there are all of those and more. So you choose ONE for the message-passing mechanism. If the process does not incorporate code that opens a pipe and reads from it, you cannot force it to do so. Alternatively, there are all of these and you want to add VMCALL to that soup as well. > There's no fundamental reason shared memory should be less safe than sockets (say); ultimately it's just bytes. We're talking about a unikernel writing to the hypervisor's address space. A bug in the hypervisor's validation (or another exploit) will allow it to overwrite arbitrary memory in the hypervisor. Sockets will not.
  - lmm 9y ago
    > So you choose ONE for the message-passing mechanism. If the process does not incorporate code that opens a pipe and reads from it, you cannot force it to do so. But then you find that somewhere in the lower layers of the framework/interpreter you were using there's something that relies on it. You disable all the sysctls you thought you weren't using and then your image library turns out to need them. Once the functionality has ever existed in the ecosystem, it's very hard to get away from. > Alternatively, there are all of these and you want to add VMCALL to that soup as well. I want to deprecate all the others at the same time, otherwise there would indeed be no point. > We're talking about a unikernel writing to the hypervisor's address space. A bug in the hypervisor's validation (or another exploit) will allow it to overwrite arbitrary memory in the hypervisor. Sockets will not. What's the difference between a unikernel sending data to the hypervisor and a process sending data to the kernel? The data always has to cross the boundary one way or another. Why would one approach be any more or less safe than the other?
    - zvrba 9y ago
      > But then you find that somewhere in the lower layers of the framework/interpreter you were using there's something that relies on it. So you refrain from using the framework in question because the very same framework wouldn't work at all in the hypothetical VM because files do not exist there. You have to write everything from scratch using only your IPC mechanism of choice, just like with VMCALL. > What's the difference between a unikernel sending data to the hypervisor and a process sending data to the kernel? Ultimately, trust. 1. The developers. I have more confidence in the implementors of, say, Linux kernel, than in developers of, say, Chrome or Firefox or Safari. 2. Testing. Kernels routinely handle successfully vastly more corner-cases than web-browsers. [Yes, I see upon all of current Linux, Windows, etc. installations as continuous, live, in-production testing.] If kernels were as shabby as today's browsers, nobody would use them for anything but toys. On the other hand, try to find a person who gets genuinely surprised when a web browser crashes.

by zvrba 9y ago

jsjohnst 9y ago

I would argue they are roughly comparable, not one better than the other. The risk profile is similar and the common CVEs are the same between the two.

mato 9y ago

Pipes and sockets on a local system are usually implemented using shared memory. While there are challenges to implementing secure* shared memory interfaces, it has been done (see eg. SEL4, QNX and many others). * For example, DoS-safe

zvrba 9y ago
> Pipes and sockets on a local system are usually implemented using shared memory. ... where the sharing is mediated by the kernel. You can't access the pipe/socket buffers directly from a user-space program. EDIT: IIRC, POSIX message queues, at least on Solaris, are implemented SHM and clever queue bookkeeping. But MQs are not sockets or pipes.

lmm 9y ago

If there was only one of pipes, sockets, system calls, and the filesystem, that would be fine. Instead there are all of those and more. There's no fundamental reason shared memory should be less safe than sockets (say); ultimately it's just bytes. Shared memory has a bad reputation because of how it behaves when processes sharing memory run concurrently, especially if they're both writing, but that's not a concern when we're talking about a unikernel interacting with the host, because there's no need to have anything happen concurrently there.

zvrba 9y ago
> If there was only one of pipes, sockets, system calls, and the filesystem, that would be fine. Instead there are all of those and more. So you choose ONE for the message-passing mechanism. If the process does not incorporate code that opens a pipe and reads from it, you cannot force it to do so. Alternatively, there are all of these and you want to add VMCALL to that soup as well. > There's no fundamental reason shared memory should be less safe than sockets (say); ultimately it's just bytes. We're talking about a unikernel writing to the hypervisor's address space. A bug in the hypervisor's validation (or another exploit) will allow it to overwrite arbitrary memory in the hypervisor. Sockets will not.
- lmm 9y ago
  > So you choose ONE for the message-passing mechanism. If the process does not incorporate code that opens a pipe and reads from it, you cannot force it to do so. But then you find that somewhere in the lower layers of the framework/interpreter you were using there's something that relies on it. You disable all the sysctls you thought you weren't using and then your image library turns out to need them. Once the functionality has ever existed in the ecosystem, it's very hard to get away from. > Alternatively, there are all of these and you want to add VMCALL to that soup as well. I want to deprecate all the others at the same time, otherwise there would indeed be no point. > We're talking about a unikernel writing to the hypervisor's address space. A bug in the hypervisor's validation (or another exploit) will allow it to overwrite arbitrary memory in the hypervisor. Sockets will not. What's the difference between a unikernel sending data to the hypervisor and a process sending data to the kernel? The data always has to cross the boundary one way or another. Why would one approach be any more or less safe than the other?
  - zvrba 9y ago
    > But then you find that somewhere in the lower layers of the framework/interpreter you were using there's something that relies on it. So you refrain from using the framework in question because the very same framework wouldn't work at all in the hypothetical VM because files do not exist there. You have to write everything from scratch using only your IPC mechanism of choice, just like with VMCALL. > What's the difference between a unikernel sending data to the hypervisor and a process sending data to the kernel? Ultimately, trust. 1. The developers. I have more confidence in the implementors of, say, Linux kernel, than in developers of, say, Chrome or Firefox or Safari. 2. Testing. Kernels routinely handle successfully vastly more corner-cases than web-browsers. [Yes, I see upon all of current Linux, Windows, etc. installations as continuous, live, in-production testing.] If kernels were as shabby as today's browsers, nobody would use them for anything but toys. On the other hand, try to find a person who gets genuinely surprised when a web browser crashes.