From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 320A1173 for ; Fri, 7 Jan 2022 19:16:19 +0000 (UTC) Received: by mail-lf1-f50.google.com with SMTP id p13so18930114lfh.13 for ; Fri, 07 Jan 2022 11:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UBa8TIub3c8pRJx3V/U7Z+AnL0F11KM1pHQYfYCQSfE=; b=KrbM0oijNYC/s0QrkLzFOE4pJ7VfLV2sz3ZRQE4BmZLvBBiYqz8BLiPARQR6ypW7cC 6LkELtaavqygIW+B1d4TlVGnWfoy+RFpt6Q7FXgF2C8XuPkXqXIiOV5HAKHDDnx6tzfu LXVkI3V/mrFHfRuJsnvzyDwJDWoFFvquCfvRd3kiBzhxY6vqs6soJkppLxjW0ZbWegZh GexGcqkRdPZ8ERdcu6VbK6E+kKAeg5oLNZZ6MW+y1Bz5caWPGLLUzGiXrhQa96tn6IBu EAQDTyr4xELOqYbB/Dud+Car+0NPN2JyCHWjfYncMgHPplFRCdrSSpOpg1JRJhA/QN40 RXPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UBa8TIub3c8pRJx3V/U7Z+AnL0F11KM1pHQYfYCQSfE=; b=DzkUpUsK1xklRaUT/eixOZYOrA1qaUzRlmTuYmJO4ni5V10s2KRI9iUchKhOgIOQb6 AoYtBsIDCFu6GWM+FZTQrzNDuaYY53SfLQYD+z7+dYCVEhLFKUDojK5MUP/WqQaasmDp YM1z0rChXBW8OYmtkgZ+lDi/PdyzEvCZq6hRnHx9ZsdkB3FTp4bgVg9k9KxvsSxaphTq UNUyVvjWhZDPl0Zo8TeUcEtOgx+P4Rnf2ijBlMfi+KtLb9osarope/F5NNz+D2VlDlzu jIRT0tukB5vZujMaLkX+ERyxMaaiQOxMlmUWXZHymfgYJc8JDUFaz5fK6DQd1u9pzhVG mlrw== X-Gm-Message-State: AOAM530V4r/4OUStftGahnqtVQ1mby6izzi18xreRM+MCxS5eIfVYJvD kw5tn+QZ8NwZFnFzgZuHQmlg1bzSmebBpdhSkbsnWQ== X-Google-Smtp-Source: ABdhPJwc9hFf6RV7zJN6Wxk7n3MNRt1wyKE1/d66jX9gd/5RqFCaxpNL4bWnd1Ly12Sdc+RlpTZsyMeHdFr707d9p7U= X-Received: by 2002:a05:6512:2828:: with SMTP id cf40mr56909749lfb.644.1641582977032; Fri, 07 Jan 2022 11:16:17 -0800 (PST) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20211129114251.3741721-1-dovmurik@linux.ibm.com> <0280e20e-8459-dd35-0b7d-8dbc1e4a274a@linux.ibm.com> In-Reply-To: From: Peter Gonda Date: Fri, 7 Jan 2022 12:16:05 -0700 Message-ID: Subject: Re: [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area To: Borislav Petkov Cc: "Dr. David Alan Gilbert" , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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. 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. > > -- > Regards/Gruss, > Boris. > > SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG N=C3= =BCrnberg >