linux-kernel - Re: [PATCH v2] docs: security: Confidential computing intro and threat model for x86 virtualization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Jun 2023 17:36:23 +0200
From:   Dmytro Maluka <dmy@...ihalf.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Carlos Bilbao <carlos.bilbao@....com>, corbet@....net,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        ardb@...nel.org, kraxel@...hat.com, dovmurik@...ux.ibm.com,
        elena.reshetova@...el.com, dave.hansen@...ux.intel.com,
        Dhaval.Giani@....com, michael.day@....com,
        pavankumar.paluri@....com, David.Kaplan@....com,
        Reshma.Lal@....com, Jeremy.Powell@....com,
        sathyanarayanan.kuppuswamy@...ux.intel.com,
        alexander.shishkin@...ux.intel.com, thomas.lendacky@....com,
        tglx@...utronix.de, dgilbert@...hat.com,
        gregkh@...uxfoundation.org, dinechin@...hat.com,
        linux-coco@...ts.linux.dev, berrange@...hat.com, mst@...hat.com,
        tytso@....edu, jikos@...nel.org, joro@...tes.org, leon@...nel.org,
        richard.weinberger@...il.com, lukas@...ner.de, jejb@...ux.ibm.com,
        cdupontd@...hat.com, jasowang@...hat.com, sameo@...osinc.com,
        bp@...en8.de, security@...nel.org,
        Larry Dewey <larry.dewey@....com>, android-kvm@...gle.com,
        Dmitry Torokhov <dtor@...gle.com>,
        Allen Webb <allenwebb@...gle.com>,
        Tomasz Nowicki <tn@...ihalf.com>,
        Grzegorz Jaszczyk <jaz@...ihalf.com>,
        Patryk Duda <pdk@...ihalf.com>
Subject: Re: [PATCH v2] docs: security: Confidential computing intro and
 threat model for x86 virtualization

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.