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> <CAEWA0a6hteJsvkd7Fe06P93O0GcE=4izSvJEj3RGpYPta9=s1w@mail.gmail.com>
In-Reply-To: <CAEWA0a6hteJsvkd7Fe06P93O0GcE=4izSvJEj3RGpYPta9=s1w@mail.gmail.com>
From:   Andrei Vagin <avagin@google.com>
Date:   Mon, 22 Aug 2022 13:26:30 -0700
Message-ID: <CAEWA0a4Ryb+REb29+yAnXeZy=kaYtwYkBjrmW5EN8=P14O8EJQ@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 6:03 PM Andrei Vagin <avagin@google.com> wrote:
>
> 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.

Thomas,

I found that the idea of a lightweight signal implementation can be interesting
in a slightly different context. I have a prototype of a gVisor platform that
uses seccomp to trap guest system calls. Guest threads are running in stub
processes that are used to manage guest address spaces.  Each stub process sets
seccomp filters to trap all system calls and it has a signal handler for
 SIGTRAP, SIGSEGV, SIGFPU, SIGILL, and SIGBUS. Each time when one of these
signals is triggered, the signal handler notifies the Sentry about it. This
platform has two obvious problems:

* It requires context switching.
* Signals are expensive.

The first one can be solved with umcg which allows doing synchronous context
switches between processes.  A lightweight signal implementation can solve the
second problem.

Do you have any concrete ideas on how to do that?

Thanks,
Andrei