From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web09.3845.1618473546685959442 for ; Thu, 15 Apr 2021 00:59:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aejh2gLD; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: pbonzini@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618473545; 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=uqdITXsJ27Ser01LSZV1xa1hf+sLoXyxpVC6xmeR/Mg=; b=aejh2gLDHP2y2rwq2TzSqbjswLselzJ6UeXsBWWsKxhd+BpnWvwv3wYAWqpOV+JJxwVX92 tTOl1iqZSlH4gyCuGZ2FdZyNNQEFAHWopJb1vLwvq4Qcy5g5kUIzxmeV6qBY7LAbiymdPt QG6GGHnvILdt41nO/4p/4GWZsEm9DI0= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-595-Nr6ZuA6SNBqHADn6isJz6g-1; Thu, 15 Apr 2021 03:59:04 -0400 X-MC-Unique: Nr6ZuA6SNBqHADn6isJz6g-1 Received: by mail-ed1-f72.google.com with SMTP id m18-20020a0564025112b0290378d2a266ebso4730331edd.15 for ; Thu, 15 Apr 2021 00:59:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uqdITXsJ27Ser01LSZV1xa1hf+sLoXyxpVC6xmeR/Mg=; b=TXIMbiRriCNtMc0aFx4pta5szgB377cDjuLAbg9mS/n3kTCyxC4fyOGzpSMqkfeKo0 45sK/wPyjBsdOtFkYitkROE/aZsER/67fpbGJ075NiYVTZ/V4XOAOqSS6rn1DhRcUFFm UvW4ZprKNQV77eN1PqCLh1PfNWS3rjH/Zxj6+32kp3QhdBPS8GJXBp7zAolY5Lns9i8Y NtK/zKRocBTul/ZtQa0lsKFRQl5xhm8/XULWX4IInw7z8m8HQfy12LEUH5uvPLMBOVZX Z+JqwBr8cdl5rCKQgVnnX8OPKrCDVUtF5ZnKzX7LPLCR/0TOh5UsTfHlXUO6m+5m91uJ kR8Q== X-Gm-Message-State: AOAM530zbohO3oyjMoyZt5lwR/sl5iR9IObI0lMnJF7DIGSCw6OpQqso GiWSoUU71Hj+BmXE2ju6Yvtzp/OXZVC0+cGpzkwlM5NMdiSkZlGeIKWfO4Z105+PMBFAdUBYx1B d9l9tHhOURTaGbg== X-Received: by 2002:a17:906:1519:: with SMTP id b25mr2114659ejd.254.1618473542934; Thu, 15 Apr 2021 00:59:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzT2Wlp7xM0+aZPdL0gqTWSulscE8s9a5Eyyv88wSzBPze7ayiGdNOK6XLMqczcJipQoVjp4A== X-Received: by 2002:a17:906:1519:: with SMTP id b25mr2114629ejd.254.1618473542735; Thu, 15 Apr 2021 00:59:02 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:b07:6468:f312:5e2c:eb9a:a8b6:fd3e? ([2001:b07:6468:f312:5e2c:eb9a:a8b6:fd3e]) by smtp.gmail.com with ESMTPSA id t15sm1132214edr.55.2021.04.15.00.59.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Apr 2021 00:59:02 -0700 (PDT) Subject: Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest] To: Erdem Aktas , devel@edk2.groups.io, jejb@linux.ibm.com Cc: "Yao, Jiewen" , "dgilbert@redhat.com" , Laszlo Ersek , "Xu, Min M" , "thomas.lendacky@amd.com" , Brijesh Singh , "Justen, Jordan L" , Ard Biesheuvel , Nathaniel McCallum 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> From: "Paolo Bonzini" Message-ID: Date: Thu, 15 Apr 2021 09:59:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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? 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. > 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). Thanks, Paolo