From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by mx.groups.io with SMTP id smtpd.web11.495.1618515780341365372 for ; Thu, 15 Apr 2021 12:43:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20161025 header.b=QK5ycBtP; spf=pass (domain: google.com, ip: 209.85.210.176, mailfrom: erdemaktas@google.com) Received: by mail-pf1-f176.google.com with SMTP id c17so16771504pfn.6 for ; Thu, 15 Apr 2021 12:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N0oIuQA4lg7DxU/uXcZaO+IqliVpKbGlMwnp2ESDYbI=; b=QK5ycBtPCczYumyLsnLECIZGU7ZCVrKeavHpp0CCatCncf/8PK1MvdmnjBUTNP8zrV a4yala1dZC8Za3SDx5/1PWraOq/iMR1k/AG4HFGL4qaZyPGejBMjH1hd2KGykt5MvVuQ zqyaqZO3rWt/jVlGNOUWKp9253TPPKyh1NEc2YA0WbDabcHeehobwiOFeSzy5hRBGSHW EJ6vnyKazN/JYJYZ3fHzyj+zIXSURgvBwxFVuqzOUBcT7pItklRv88614GLyaSGuzgPb Nsc3+7setv1Dy6qBXohRJxRFhSVU2EcqlYMNXwKj20Ffo31vQinhZgNPaz1rl+MLd84L vTrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N0oIuQA4lg7DxU/uXcZaO+IqliVpKbGlMwnp2ESDYbI=; b=YMI6ekQ6Bj4lkKslKOMXPUKDcdWe5HFGEIpB3u/xKUaPh3zIAF4g7hg63jDYM+MEl5 uPrSEB6rl4Kv7/XyQ3LdwCaNYiir4IT+kIq7Vv9THGYTznArwqw2U3r9OmGf5mJ+hX6G tXUyn000qvNTXb6ZUbOBvOTZUgvTF7UqIBJWop2wbF1KiCtbNtt1MYTo1HsJmRHrkb7C l5yD8lfK7vXpG/A5H8prfv4ko6XKMPQk2xJm/u8x2ESp7twTeJopQooC/MVESpTH9QyS xAUmVT96T9XxjWP4FsxOCOS0QxJ3JBKTcfWrIuo2V0vQao/bCd3DQBviurAdMnHtkFm/ HaqQ== X-Gm-Message-State: AOAM533ETZ3UAOTCJOSgfCi8DKXthAZYKTpPVNIq+/gpBhsUVzkoFVw5 knva3ygrRLIWZLY4CYsNF6S9UKLzWpQyZDOGMlLP0A== X-Google-Smtp-Source: ABdhPJxDEWTlr/9seot3em6C2O/2Y61bgfLoeE/nYG8V3VGyvc9zBTVrVFQpX9Gt+rwWnjmY/+Wp7K2T5Cab9Nrb0+Q= X-Received: by 2002:a63:e552:: with SMTP id z18mr4935437pgj.100.1618515779485; Thu, 15 Apr 2021 12:42:59 -0700 (PDT) MIME-Version: 1.0 References: <719a63e555376ca65a7bbe0c7e23c20b6b631cd3.camel@linux.ibm.com> <9aa00ba0-def0-9a4e-1578-0b55b8047ebd@redhat.com> <2ff2c569-1032-3e5f-132a-159c47c9f067@amd.com> <18180548-016d-4e37-68fd-050dfc3b4e77@redhat.com> <5183d5fd-9bba-6f0a-52e0-a3e27a6784de@redhat.com> In-Reply-To: From: "Erdem Aktas" Date: Thu, 15 Apr 2021 12:42:49 -0700 Message-ID: Subject: Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest] To: Paolo Bonzini Cc: devel@edk2.groups.io, jejb@linux.ibm.com, "Yao, Jiewen" , "dgilbert@redhat.com" , Laszlo Ersek , "Xu, Min M" , "thomas.lendacky@amd.com" , Brijesh Singh , "Justen, Jordan L" , Ard Biesheuvel , Nathaniel McCallum , Ning Yang Content-Type: text/plain; charset="UTF-8" Thanks Paolo. On Thu, Apr 15, 2021 at 12:59 AM Paolo Bonzini wrote: > > On 15/04/21 01:34, Erdem Aktas wrote: > > We do not want to generate different binaries for AMD, Intel, Intel > > with TDX, AMD with SEV/SNP etc > > My question is why the user would want a single binary for VMs with and > without TDX/SNP. I know there is attestation, but why would you even > want the _possibility_ that your guest starts running without TDX or SNP > protection, and only find out later via attestation? There might be multiple reasons why customers want it but we need this requirement for a couple of other reasons too. We do not only have hardware based confidential VMs. We might have some other solutions which measure the initial image before boot. Ultimately we might want to use a common attestation interface where customers might be running different kinds of VMs. Using a single binary will make it easier to manage/verify measurements for both of us and the customers. I am not a PM so I cannot give more context on customer use cases. Another reason is how we deploy and manage guest firmware. We have a lot of optimization and customization to speed up firmware loading time and also reduce the time to deploy new builds on the whole fleet uniformly. Adding a new firmware binary is a big challenge for us to enable these features. On the top of integration challenges, it will create maintainability issues in the long run for us when we provide tools to verify/reproduce the hashes in the attestation report. > want the _possibility_ that your guest starts running without TDX or SNP > protection, and only find out later via attestation? I am missing the point here. Customers should rely on only the attestation report to establish the trust. -If firmware does not support TDX and TDX is enabled, that firmware will crash at some point. -If firmware is generic firmware that supports TDX and SNP and others, and TDX is enabled or not, still the customer needs to verify the TDX enablement through attestation. -If firmware is a customized binary compiled to support TDX, irrelevant of TDX being enabled or not, still the customer needs to verify the TDX enablement through attestation. > For a similar reason, OVMF already supports shipping a binary that fails > to boot if SMM is not available to the firmware, because then secure > boot would be trivially circumvented. > > I can understand having a single binary for both TDX or SNP. That's not > a problem since you can set up the SEV startup VMSA to 32-bit protected > mode just like TDX wants. I agree that this is doable but I am not sure if we need to also modify the reset vector for AMD SNP in that case. Also it will not solve our problem. If we start to generate a new firmware for every feature , it will not end well for us, I think. Both TDX and SNP are still new features in the same architecture, and it seems to me that they are sharing a lot of common/similar code. AMD has already made some of their patches in (SEV and SEV-ES) which works very nicely for our use case and integration. Looks like Intel just has an issue on how to fix their reset vector problem. Once they solve it and upstream accepts the changes, I do not see any other big blocker. OVMF was doing a great job on abstracting differences and providing a common interface without creating multiple binaries. I do not see why it should not do the same thing here. > > therefore we were expecting the TDX > > changes to be part of the upstream code. > > Having 1 or more binaries should be unrelated to the changes being > upstream (or more likely, I am misunderstanding you). You are right, it is my bad for not clarifying it. What I mean is we want it to be part of the upstream so it can be easier for us to pull the changes and they are compatible with the changes that SNP is doing but we also do not want to use different configuration files to generate different binaries for each use case. > Thanks, > > Paolo >