> 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 mak

> 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...