Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220722230241.1944655-1-avagin@google.com> <Yts1tUfPxdPH5XGs@google.com>
 <CAEWA0a4hrRb5HYLqa1Q47=guY6TLsWSJ_zxNjOXXV2jCjUekUA@mail.gmail.com>
 <YuAD6qY+F2nuGm62@google.com> <875yjjttiz.ffs@tglx>
In-Reply-To: <875yjjttiz.ffs@tglx>
From:   Andrei Vagin <avagin@google.com>
Date:   Tue, 26 Jul 2022 18:03:44 -0700
Message-ID: <CAEWA0a6hteJsvkd7Fe06P93O0GcE=4izSvJEj3RGpYPta9=s1w@mail.gmail.com>
Subject: Re: [PATCH 0/5] KVM/x86: add a new hypercall to execute host system
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Sean Christopherson <seanjc@google.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        Wanpeng Li <wanpengli@tencent.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Jianfeng Tan <henry.tjf@antfin.com>,
        Adin Scannell <ascannell@google.com>,
        Konstantin Bogomolov <bogomolov@google.com>,
        Etienne Perot <eperot@google.com>,
        Andy Lutomirski <luto@kernel.org>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Jul 26, 2022 at 3:10 PM Thomas Gleixner <tglx@linutronix.de> 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
>