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;
Date:   Fri, 16 Jun 2023 07:20:07 -0700
In-Reply-To: <2cfa3122-6b54-aab5-8a61-41c08853286b@semihalf.com>
Mime-Version: 1.0
References: <20230612164727.3935657-1-carlos.bilbao@amd.com>
 <ZIihRqZljMaMRGcK@google.com> <2cfa3122-6b54-aab5-8a61-41c08853286b@semihalf.com>
Message-ID: <ZIxvl4sMH6N8TrAL@google.com>
Subject: Re: [PATCH v2] docs: security: Confidential computing intro and
 threat model for x86 virtualization
From:   Sean Christopherson <seanjc@google.com>
To:     Dmytro Maluka <dmy@semihalf.com>
Cc:     Carlos Bilbao <carlos.bilbao@amd.com>, corbet@lwn.net,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        ardb@kernel.org, kraxel@redhat.com, dovmurik@linux.ibm.com,
        elena.reshetova@intel.com, dave.hansen@linux.intel.com,
        Dhaval.Giani@amd.com, michael.day@amd.com,
        pavankumar.paluri@amd.com, David.Kaplan@amd.com,
        Reshma.Lal@amd.com, Jeremy.Powell@amd.com,
        sathyanarayanan.kuppuswamy@linux.intel.com,
        alexander.shishkin@linux.intel.com, thomas.lendacky@amd.com,
        tglx@linutronix.de, dgilbert@redhat.com,
        gregkh@linuxfoundation.org, dinechin@redhat.com,
        linux-coco@lists.linux.dev, berrange@redhat.com, mst@redhat.com,
        tytso@mit.edu, jikos@kernel.org, joro@8bytes.org, leon@kernel.org,
        richard.weinberger@gmail.com, lukas@wunner.de, jejb@linux.ibm.com,
        cdupontd@redhat.com, jasowang@redhat.com, sameo@rivosinc.com,
        bp@alien8.de, security@kernel.org,
        Larry Dewey <larry.dewey@amd.com>, android-kvm@google.com,
        Dmitry Torokhov <dtor@google.com>,
        Allen Webb <allenwebb@google.com>,
        Tomasz Nowicki <tn@semihalf.com>,
        Grzegorz Jaszczyk <jaz@semihalf.com>,
        Patryk Duda <pdk@semihalf.com>
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Fri, Jun 16, 2023, Dmytro Maluka wrote:
> On 6/13/23 19:03, Sean Christopherson wrote:
> > On Mon, Jun 12, 2023, Carlos Bilbao wrote:
> >> +well as CoCo technology specific hypercalls, if present. Additionally, the
> >> +host in a CoCo system typically controls the process of creating a CoCo
> >> +guest: it has a method to load into a guest the firmware and bootloader
> >> +images, the kernel image together with the kernel command line. All of this
> >> +data should also be considered untrusted until its integrity and
> >> +authenticity is established via attestation.
> > 
> > Attestation is SNP and TDX specific.  AIUI, none of SEV, SEV-ES, or pKVM (which
> > doesn't even really exist on x86 yet), have attestation of their own, e.g. the
> > proposed pKVM support would rely on Secure Boot of the original "full" host kernel.
> 
> Seems to be a bit of misunderstanding here. Secure Boot verifies the
> host kernel, which is indeed also important, since the pKVM hypervisor
> is a part of the host kernel image. But when it comes to verifying the
> guests, it's a different story: a protected pKVM guest is started by the
> (untrusted) host at an arbitrary moment in time, not before the early
> kernel deprivileging when the host is still considered trusted.
> (Moreover, in practice the guest is started by a userspace VMM, i.e. not
> exactly the most trusted part of the host stack.) So the host can
> maliciously or mistakenly load a wrong guest image for running as a
> protected guest, so we do need attestation for protected guests.
> 
> This attestation is not implemented in pKVM on x86 yet (you are right
> that pKVM on x86 is little more than a proposal at this point). But in
> pKVM on ARM it is afaik already working, it is software based (ensured
> by pKVM hypervisor + a tiny generic guest bootloader which verifies the
> guest image before jumping to the guest) and architecture-independent,
> so it should be possible to adopt it for x86 as is.

Sorry, instead of "Attestation is SNP and TDX specific", I should have said, "The
form of attestation described here is SNP and TDX specific".

pKVM's "attestation", effectively has its root of trust in the pKVM hypervisor,
which is in turn attested via Secure Boot.  I.e. the guest payload is verified
*before* it is launched.

That is different from SNP and TDX where guest code and data is controlled by the
*untrusted* host.  The initial payload is measured by trusted firmware, but it is
not verified, and so that measurement must be attested after the guest boots,
before any sensitive data is provisioned to the guest.

Specifically, with "untrusted" inserted by me for clarification, my understanding
is that this doesn't hold true for pKVM when splitting hairs:

  Additionally, the **untrusted** host in a CoCo system typically controls the
  process of creating a CoCo guest: it has a method to load into a guest the
  firmware and bootloader images, the kernel image together with the kernel
  command line. All of this data should also be considered untrusted until its
  integrity and authenticity is established via attestation.

because the guest firmware comes from a trusted entity, not the untrusted host.