4 ms·

I recommend reading the GitHub README[1]. > I don't really understand what the benefit is over seccomp-bpf With seccomp-bpf you are filtering what syscalls ca

I recommend reading the GitHub README[1]. > I don't really understand what the benefit is over seccomp-bpf With seccomp-bpf you are filtering what syscalls can be made, but those syscall still happen in the host kernel. If that kernel syscall has a vulnerability it could allow exploitation of the host and other containers in a multi-tenancy environment. The gVisor kernel actually implements the syscalls, it doesn't just pass them on. > Advisor appears to be working on a KVM shim, but I'm not quite sure how you can use KVM and still differentiate yourself from Kata Containers Kata Containers virtualize hardware and run a regular Linux kernel on the virtual hardware. gVisor doesn't virtualize hardware, it is a kernel running in userspace, implementing syscalls. > I just re-read the article and it looks like they don't actually use containers at all. Unless I'm mistaken this means that they are not taking advantage of any of the sophisticated security primitives in the kernel that ordinary containers use, and thus have the same (bad) security model as UML. The gVisor kernel (Sentry) runs in an empty user namespace with seccomp filters applied. [1] https://github.com/google/gvisor https://github.com/google/gvisor

cyphar 8y ago
> With seccomp-bpf you are filtering what syscalls can be made, but those syscall still happen in the host kernel. I'm not sure what the distinction you're making is. By the same token, because PTRACE_SYSCALL/PTRACE_SYSEMU only signals the calling process after the syscall boundary has been crossed, then ptrace also doesn't help with the problem you are describing (though I also don't really agree that it's a problem in the first place -- user-kernel context switches are not security vulnerabilities). In fact, the seccomp restrictions are applied immediately after PTRACE_SYSCALL/PTRACE_SYSEMU -- there is only a few lines of code separating the two cases in the syscall entry path[1]. And in the case of PTRACE_SYSEMU, seccomp rules are still executed even though the syscall is never going to be executed. > gVisor doesn't virtualize hardware, it is a kernel running in userspace, implementing syscalls. I understand that, but that's the ptrace helper (which I spent the rest of my comment talking about). In the README (which I did read before commenting) they mention an experimental KVM driver, which is what my VM comments were referring to. Is there an explanation somewhere about how gVisor uses KVM to virtualize syscalls? I'm not sure I understand how you could use KVM to do that. That's why I mentioned Kata, because it's the only point of reference I have for using KVM to "emulate syscalls" (though of course it emulates more than that). > The gVisor kernel (Sentry) runs in an empty user namespace with seccomp filters applied. Good to know, but I didn't see that mentioned anywhere? If you're affiliated with the project it'd be great if you could add it somewhere in the README or the blog post. [1]: https://elixir.bootlin.com/linux/v4.16.6/source/arch/x86/entry/common.c#L81 https://elixir.bootlin.com/linux/v4.16.6/source/arch/x86/ent...
- ithkuil 8y ago
  I started by reading here https://github.com/google/gvisor/blob/master/pkg/sentry/platform/kvm/kvm.go https://github.com/google/gvisor/blob/master/pkg/sentry/plat... Basically the Sentry binary works as both the VMM and the guest kernel. It uses the KVM API to setup page an address space and installs fault handlers through which it regains control when the guest payload faults (on memory access or soft interrupts/sysenter). What I couldn't find on a quick skin is how much of that logic works on which "side" of the wall, i.e. how much logic can the Sentry evaluate without crossing the VM boundary. I can imagine this can depend quite a lot on Go runtime internals. How do you setup the environment inside the "guest" so that it can run the Go code?

cyphar 8y ago

> With seccomp-bpf you are filtering what syscalls can be made, but those syscall still happen in the host kernel. I'm not sure what the distinction you're making is. By the same token, because PTRACE_SYSCALL/PTRACE_SYSEMU only signals the calling process after the syscall boundary has been crossed, then ptrace also doesn't help with the problem you are describing (though I also don't really agree that it's a problem in the first place -- user-kernel context switches are not security vulnerabilities). In fact, the seccomp restrictions are applied immediately after PTRACE_SYSCALL/PTRACE_SYSEMU -- there is only a few lines of code separating the two cases in the syscall entry path[1]. And in the case of PTRACE_SYSEMU, seccomp rules are still executed even though the syscall is never going to be executed. > gVisor doesn't virtualize hardware, it is a kernel running in userspace, implementing syscalls. I understand that, but that's the ptrace helper (which I spent the rest of my comment talking about). In the README (which I did read before commenting) they mention an experimental KVM driver, which is what my VM comments were referring to. Is there an explanation somewhere about how gVisor uses KVM to virtualize syscalls? I'm not sure I understand how you could use KVM to do that. That's why I mentioned Kata, because it's the only point of reference I have for using KVM to "emulate syscalls" (though of course it emulates more than that). > The gVisor kernel (Sentry) runs in an empty user namespace with seccomp filters applied. Good to know, but I didn't see that mentioned anywhere? If you're affiliated with the project it'd be great if you could add it somewhere in the README or the blog post. [1]: https://elixir.bootlin.com/linux/v4.16.6/source/arch/x86/entry/common.c#L81 https://elixir.bootlin.com/linux/v4.16.6/source/arch/x86/ent...

ithkuil 8y ago
I started by reading here https://github.com/google/gvisor/blob/master/pkg/sentry/platform/kvm/kvm.go https://github.com/google/gvisor/blob/master/pkg/sentry/plat... Basically the Sentry binary works as both the VMM and the guest kernel. It uses the KVM API to setup page an address space and installs fault handlers through which it regains control when the guest payload faults (on memory access or soft interrupts/sysenter). What I couldn't find on a quick skin is how much of that logic works on which "side" of the wall, i.e. how much logic can the Sentry evaluate without crossing the VM boundary. I can imagine this can depend quite a lot on Go runtime internals. How do you setup the environment inside the "guest" so that it can run the Go code?