4 ms·
> This VM would not have an IP stack but a small, secure, and well defined interface. It can basically do two or three things to communicate with the host: [...
by zvrba 9y ago
> This VM would not have an IP stack but a small, secure, and well defined interface. It can basically do two or three things to communicate with the host: [...] All of these mechanisms can be transported out of the VM through hypercall (like VMCALL).
So how is this better than using existing IPC mechanisms and using the "user" abstraction to separate privileges?
And how is this more secure then IPC to a process running under another user given
> The browser takes a careful look at the pointer and the data it is pointing at. This code will need to be properly vetted as a buffer overflow here could potentially allow the unikernel to execute code outside its hardware prison.
(The long list of CVEs tells us how good programmers are at "properly vetting" buffers).
- noway421 9y agoAs far as i understood, it is single point of failure and something that browser developers would need to ensure, not end developers. It's possible to cover that specific part with extensive testing and fuzzing to make sure it's robust.
- lmm 9y ago> So how is this better than using existing IPC mechanisms and using the "user" abstraction to separate privileges? It's a smaller, cleaner, interface that's been designed from day 1 to be secure, rather than having security awkwardly partially retrofitted. > (The long list of CVEs tells us how good programmers are at "properly vetting" buffers). Right, which is exactly why it's vital to keep those interfaces as small as possible, rather than having dozens of different IPC mechanisms for vulnerabilities to hide in.
- 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 agoI 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 agoPipes 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 agoIf 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.