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]
Message-ID: <2cfa3122-6b54-aab5-8a61-41c08853286b@semihalf.com>
Date:   Fri, 16 Jun 2023 14:24:19 +0200
From:   Dmytro Maluka <dmy@...ihalf.com>
To:     Sean Christopherson <seanjc@...gle.com>,
        Carlos Bilbao <carlos.bilbao@....com>
Cc:     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/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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ