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: <2cfa3122-6b54-aab5-8a61-41c08853286b@semihalf.com>
Date:   Fri, 16 Jun 2023 14:24:19 +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
To:     Sean Christopherson <seanjc@google.com>,
        Carlos Bilbao <carlos.bilbao@amd.com>
Cc:     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>
Content-Language: en-US
From:   Dmytro Maluka <dmy@semihalf.com>
In-Reply-To: <ZIihRqZljMaMRGcK@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

Furthermore, since for pKVM on x86 use cases we also need assigning
physical secure hardware devices to the protected guest, we need
attestation not just for the guest image itself but also for the secure
devices assigned to it by the host.