Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200407011259.GA72735@juliacomputing.com> <8f95e8b4-415f-1652-bb02-0a7c631c72ac@intel.com>
 <CABV8kRw1TQsqs+z43bSfZ5isctuFGMB4g_ztDYihiiXHcy4nVA@mail.gmail.com>
 <5208ad1e-cd9b-d57e-15b0-0ca935fccacd@intel.com> <CABV8kRzfR32+MpAvTAPHCN902WtHSxySujcO2yAB3OT0caVDJg@mail.gmail.com>
 <9921cb2e-a7cb-c1d0-b120-c08f06be7c7f@intel.com> <CABV8kRxDkE1dQh0c2FkFpkUruiR0aD-hXbgd5-jcoCDiwYHs1A@mail.gmail.com>
In-Reply-To: <CABV8kRxDkE1dQh0c2FkFpkUruiR0aD-hXbgd5-jcoCDiwYHs1A@mail.gmail.com>
From:   Keno Fischer <keno@juliacomputing.com>
Date:   Tue, 14 Apr 2020 15:55:07 -0400
Message-ID: <CABV8kRy6M8_-An5TEvBATAz+MxdaQqbCLBEZbJsaz=aZiV48wA@mail.gmail.com>
Subject: Re: [RFC PATCH v2] x86/arch_prctl: Add ARCH_SET_XCR0 to set XCR0 per-thread
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andi Kleen <andi@firstfloor.org>,
        Kyle Huey <khuey@kylehuey.com>,
        "Robert O'Callahan" <robert@ocallahan.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi everyone,

I'd like to continue this discussion along two directions:

1) In this patch, what should happen to signal frames?

I continue to think that it would be good for these to observe
the process' XCR0, but I understand the argument that we
should not let the XCR0 setting modify any kernel behavior
whatsoever. Andy, I would in particular appreciate your views
on this since I believe you thought it should do the latter.

2) What would a solution based on the raw KVM API look like?

I'm still afraid that going down the KVM route would just end up
back in the same situation as we're in right now, but I'd like to
explore this further, so here's my current thinking: Particularly for
recording, the process does need to look very much like a regular
linux process, so we can get recording of syscalls and signal state right.
I don't have enough of an intuition for the performance implications
of this. For example, suppose we added a way for the kernel to
directly take syscalls from guest CPL3 - what would the cost
of incurring a vmexit for every syscall be? I suppose another
idea would be to build a minimal linux kernel that sits in guest
CPL0 and emulates at least the process state and other high
frequency syscalls, but forwards the rest to the host kernel.
Seems potentially doable, but a bit brittle - is there prior art
here I should be aware of, e.g. from people looking at securing
containers? As I mentioned, I had looked at Project Dune
before (http://dune.scs.stanford.edu/), which does seem to
do a lot of the things I would need, though it doesn't appear
to currently be handling signals at all, and of course it's also
not really KVM based, but rather
KVM-but-copy-pasted-and-manually-hacked-up-in-a-separate.ko
based.

I may also be missing a completely obvious way to do this -
my apologies if so. I would certainly appreciate any insight on
how to achieve the set of requirements here (multiple tracees
with potentially differing XCR0 values, faithful and performant
provision of syscalls/signals to the tracees) on top of KVM.

If we can figure out a good way forward with KVM, I'd be quite
interested in it, since I think there may be additional performance
games that could be played by having part of rr be in guest CPL0,
I'm just unsure that KVM is really the right abstraction here, so
I'd like to think through it a bit.

Keno