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;
Message-ID: <ae75c890-4389-6aac-8c3d-bc9fd1df1f6b@semihalf.com>
Date:   Fri, 16 Jun 2023 17:36:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH v2] docs: security: Confidential computing intro and
 threat model for x86 virtualization
Content-Language: en-US
To:     Sean Christopherson <seanjc@google.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>
References: <20230612164727.3935657-1-carlos.bilbao@amd.com>
 <ZIihRqZljMaMRGcK@google.com>
 <2cfa3122-6b54-aab5-8a61-41c08853286b@semihalf.com>
 <ZIxvl4sMH6N8TrAL@google.com>
From:   Dmytro Maluka <dmy@semihalf.com>
In-Reply-To: <ZIxvl4sMH6N8TrAL@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 6/16/23 16:20, Sean Christopherson wrote:
> 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.

Got it, fair point. Yep, I think this understanding is fully correct.
 
> 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.