From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E13CF2C9C for ; Mon, 10 Jan 2022 16:27:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641832044; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jeIheefqGaZ2GeSClHVA0Xt4+ifFFQupgVzVvNBmh9M=; b=aV7i3PBTYwCfMwDHmHgWLe97q++ihR8hkVVLWEMoDPLedplk4tClq07q3kjUo3WQSLieYw WCEhm7fxqhmPBoKzfXtw9cRVtzqD7hreW3ryeEDm9T1qgMVy/OHlKxxnZq6QkMHZTXL55k ooGk3gjjiQCuyrieSkPnasTVnUSXNis= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-34-LWGbbB0sNXirEXhQVfKKUw-1; Mon, 10 Jan 2022 11:27:21 -0500 X-MC-Unique: LWGbbB0sNXirEXhQVfKKUw-1 Received: by mail-wm1-f71.google.com with SMTP id r2-20020a05600c35c200b00345c3b82b22so9191562wmq.0 for ; Mon, 10 Jan 2022 08:27:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=jeIheefqGaZ2GeSClHVA0Xt4+ifFFQupgVzVvNBmh9M=; b=L5ae26k1URRN01Euzh+VZgpYSiBURsPy6/4KhEWpUfP0hmTBGnD7r03yXeWhSRNDG2 Rz88jQWqdMddLMT9hErlXqYpPBPLp0nl/FKLIxDm3nKYVWLaQCihDNgfKrGnHMt13H+m hYg+zjYjmA8vWaBDHssrFhOvvJln9IGqV9UeQDV4KR5AvEahdaMjymbTTysakuwh7Eun 8W3ot7ERNEg2LacTmQK3s47SdJOKQ+OHuYhbLUPb+fgxw54YjO1+y3VKq3sJFhIWL7mR iOC4FJm0WYFzlzfENBRUN176dLICgqcBLsML453KKzKw9ZuYj2Jfgct1SHN6CwWZtjaR 1Png== X-Gm-Message-State: AOAM531V64ug+oWbTWQ5x42mCgqfX30/okQHoM4jaokq4G1rwkMVJJPd YKRaXr43xh/FLd7M4uD4CZQNZHpD04XNH+/P4ougT3E6p3Sq6PNMoYyEXoUCoy3e6Ou7LZfqVA/ 1n9iVveBA+RZmsq9n8OKpOw== X-Received: by 2002:a05:600c:1c22:: with SMTP id j34mr3870363wms.116.1641832040370; Mon, 10 Jan 2022 08:27:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJw78/dFkceXP7vi+FCTgn09bLS0ejoLHTG16lQIhQ5MhHYjaxHo78dnCGmFqnQo+pPk89TDmg== X-Received: by 2002:a05:600c:1c22:: with SMTP id j34mr3870348wms.116.1641832040150; Mon, 10 Jan 2022 08:27:20 -0800 (PST) Received: from work-vm (cpc109025-salf6-2-0-cust480.10-2.cable.virginm.net. [82.30.61.225]) by smtp.gmail.com with ESMTPSA id e13sm7183050wmq.10.2022.01.10.08.27.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 08:27:19 -0800 (PST) Date: Mon, 10 Jan 2022 16:27:17 +0000 From: "Dr. David Alan Gilbert" To: Peter Gonda Cc: Borislav Petkov , Dov Murik , Brijesh Singh , Tom Lendacky , linux-efi@vger.kernel.org, Ashish Kalra , Ard Biesheuvel , James Morris , "Serge E. Hallyn" , Andi Kleen , Greg KH , Andrew Scull , Dave Hansen , James Bottomley , Tobin Feldman-Fitzthum , Jim Cadden , Daniele Buono , linux-coco@lists.linux.dev, linux-security-module@vger.kernel.org, LKML Subject: Re: [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area Message-ID: References: <20211129114251.3741721-1-dovmurik@linux.ibm.com> <0280e20e-8459-dd35-0b7d-8dbc1e4a274a@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.1.3 (2021-09-10) Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dgilbert@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit * Peter Gonda (pgonda@google.com) wrote: > On Fri, Jan 7, 2022 at 4:59 AM Borislav Petkov wrote: > > > > On Wed, Jan 05, 2022 at 08:07:04PM +0000, Dr. David Alan Gilbert wrote: > > > I thought I saw something in their patch series where they also had a > > > secret that got passed down from EFI? > > > > Probably. I've seen so many TDX patchsets so that I'm completely > > confused what is what. > > > > > As I remember they had it with an ioctl and something; but it felt to > > > me if it would be great if it was shared. > > > > I guess we could try to share > > > > https://lore.kernel.org/r/20211210154332.11526-28-brijesh.singh@amd.com > > > > for SNP and TDX. > > > > > I'd love to hear from those other cloud vendors; I've not been able to > > > find any detail on how their SEV(-ES) systems actually work. > > > > Same here. > > > > > However, this aims to be just a comms mechanism to pass that secret; > > > so it's pretty low down in the stack and is there for them to use - > > > hopefully it's general enough. > > > > Exactly! > > > > > (An interesting question is what exactly gets passed in this key and > > > what it means). > > > > > > All the contentious stuff I've seen seems to be further up the stack - like > > > who does the attestation and where they get the secrets and how they > > > know what a valid measurement looks like. > > > > It would be much much better if all the parties involved would sit down > > and decide on a common scheme so that implementation can be shared but > > getting everybody to agree is likely hard... > > I saw a request for other cloud provider input here. Thanks for the reply! > A little > background for our SEV VMs in GCE we rely on our vTPM for attestation, > we do this because of SEV security properties quoting from AMD being > to protect guests from a benign but vulnerable hypervisor. So a > benign/compliant hypervisor's vTPM wouldn't lie to the guest. So we > added a few bits in the PCRs to allow users to see their SEV status in > vTPM quotes. OK, so we're trying to protect from a malicious hypervisor - we don't trust anything on the host (other than the CPU, and it's got to be signing the attestation); we don't think there's a way to do that with a vTPM on plain SEV/SEV-ES > It would be very interesting to offer an attestation solution that > doesn't rely on our virtual TPM. But after reading through this cover > letter and the linked OVMF patches I am confused what's the high level > flow you are working towards? Are you loading in some OVMF using > LAUNCH_UPDATE_DATA, getting the measurement with LAUNCH_MEASURE, then > sending that to the customer who can then craft a "secret" (maybe say > SSH key) for injection with LAUNCH_SECRET? Thats sounds good but there > are a lot details left unattested there, how do you know you will boot > from the image loaded with the PSP into a known state? Do you have > some documentation I could read through to try and understand a little > more and apologies if I missed it. I'll defer to Dov's reply on that. Dave > > > > -- > > Regards/Gruss, > > Boris. > > > > SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK