On Tue, Jul 26, 2022 at 3:10 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > On Tue, Jul 26 2022 at 15:10, Sean Christopherson wrote: > > On Tue, Jul 26, 2022, Andrei Vagin wrote: > >> * It doesn't allow to support Confidential Computing (SEV-ES/SGX). The Sentry > >> has to be fully enclosed in a VM to be able to support these technologies. > > > > Speaking of SGX, this reminds me a lot of Graphene, SCONEs, etc..., which IIRC > > tackled the "syscalls are crazy expensive" problem by using a message queue and > > a dedicated task outside of the enclave to handle syscalls. Would something like > > that work, or is having to burn a pCPU (or more) to handle syscalls in the host a > > non-starter? > > Let's put VMs aside for a moment. The problem you are trying to solve is > ptrace overhead because that requires context switching, right? Yes, you are right. > > Did you ever try to solve this with SYSCALL_USER_DISPATCH? That requires > signals, which are not cheap either, but we certainly could come up with > a lightweight signal implementation for that particular use case. We thought about this interface and how it could be used for gVisor needs. I think the main question is how to manage guest address spaces. gVisor can run multiple processes in one sandbox. Each process must have its address space isolated from other address spaces. The gVisor kernel (Sentry) has to run in a separate address space that guest processes don't have access to, but the Sentry has to be able to access all other address spaces. > > Thanks, > > tglx >
