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: <20200522125214.31348-1-kirill.shutemov@linux.intel.com>
 <20200604161523.39962919@why> <20200604154835.GE30223@linux.intel.com>
 <20200604163532.GE3650@willie-the-truck> <6DBAB6A4-A1F9-40E9-B81B-74182DDCF939@intel.com>
In-Reply-To: <6DBAB6A4-A1F9-40E9-B81B-74182DDCF939@intel.com>
From:   Jim Mattson <jmattson@google.com>
Date:   Thu, 4 Jun 2020 14:03:12 -0700
Message-ID: <CALMp9eRN-zkvmkYQ0a600SyLA_0ymznBG8jmriTsYMcXkK77Qg@mail.gmail.com>
Subject: Re: [RFC 00/16] KVM protected memory extension
To:     "Nakajima, Jun" <jun.nakajima@intel.com>
Cc:     Will Deacon <will@kernel.org>,
        "Christopherson, Sean J" <sean.j.christopherson@intel.com>,
        Marc Zyngier <maz@kernel.org>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Joerg Roedel <joro@8bytes.org>,
        David Rientjes <rientjes@google.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Kees Cook <keescook@chromium.org>,
        Will Drewry <wad@chromium.org>,
        "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
        "Kleen, Andi" <andi.kleen@intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        "kernel-team@android.com" <kernel-team@android.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jun 4, 2020 at 12:09 PM Nakajima, Jun <jun.nakajima@intel.com> wrot=
e:

> We (Intel virtualization team) are also working on a similar thing, proto=
typing to meet such requirements, i..e "some level of confidentiality to gu=
ests=E2=80=9D. Linux/KVM is the host, and the Kirill=E2=80=99s patches are =
helpful when removing the mappings from the host to achieve memory isolatio=
n of a guest. But, it=E2=80=99s not easy to prove there are no other mappin=
gs.
>
> To raise the level of security, our idea is to de-privilege the host kern=
el just to enforce memory isolation using EPT (Extended Page Table) that vi=
rtualizes guest (the host kernel in this case) physical memory; almost ever=
ything is passthrough. And the EPT for the host kernel excludes the memory =
for the guest(s) that has confidential info. So, the host kernel shouldn=E2=
=80=99t cause VM exits as long as it=E2=80=99s behaving well (CPUID still c=
auses a VM exit, though).

You're Intel. Can't you just change the CPUID intercept from required
to optional? It seems like this should be in the realm of a small
microcode patch.