From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by mx.groups.io with SMTP id smtpd.web08.750.1618443265251006692 for ; Wed, 14 Apr 2021 16:34:25 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20161025 header.b=CVGtkDWN; spf=pass (domain: google.com, ip: 209.85.210.178, mailfrom: erdemaktas@google.com) Received: by mail-pf1-f178.google.com with SMTP id w8so11328313pfn.9 for ; Wed, 14 Apr 2021 16:34:25 -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=JNGxQRXt0aLAVVwMPvmZ3byCAQ2bgTSjHpeDAAJK7go=; b=CVGtkDWNVVf3QFVJK3az9Dr6B70ZY9AmST1Ixd40+oDXPWesFJYmvX8OhKyoSzIXhH 2XvcAm62s4/k7ITSj2BZHYMgxfHPlIOYKVggYcS/emQyGk/Fke212b2aTRW7h8ftU06f LiDq8gWMh/AGXKbqMtCsBPFkVMPwkXdY3jE5ykh/Le7ESOXxLoQxXGXUicX0zMZTgMyk AsLQSQc886nQWYQ1E/Ubsn3fdcyTP7RbyszJ+C+ruOdKB+mAkkrvgyKV4ccE4xD0bvKX 3Df92a3uIe2o+S9ou8cZkTTK99y9UrrwcNcDe21/MPnxDTI+35kpjaDqOtLSkKaUh/re sojQ== 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=JNGxQRXt0aLAVVwMPvmZ3byCAQ2bgTSjHpeDAAJK7go=; b=oJV2githnoqTZ8wZKj7NErRBFwI5gx1r0TnAhSbc0MLkA8TQ9Ouote7NPfvvIQXBwS qyl9YsMfopvoZDQIVXRVBBM1PUyZDqhH78r2Qnhrf2qkQ8Fc7tu14+owWqGNOssookHs JuKChmSR4HrDzHKIO8C2a+8tZR9LbGSp2dKiyiie8psQP7vuBHBGiQjK2gepjdsuSKsf Ra4De7aaubehnNG9lRn3tTPmnvC0ZV4/c/9ZFJD1rVox6JZ4BuJk1kYGeFah7Af1z0/f Ox1nH9pFiZG3V+wx8nJzWxN8Ihie56awq8E12p+wBWjobvkSNoHy/qO44c40WSKpL8+x Mh9w== X-Gm-Message-State: AOAM531Bd7uXvJHkeji1mZPhcsmux/GIHMmM1Co2PGWwWrtAkRHtB0vM Qd9tgfZzdnM2YbukqJsZmEPXylfdDu93JXUgq8t8ThWcizpPjkYi X-Google-Smtp-Source: ABdhPJx1DIfJuPjz7UuPOAkvmd+fxxN/rn4eS7D/c7btZQzPpsp4eYfK84HKBGrIW77MbNHnXpekpwp/k4pcP+TMp1Y= X-Received: by 2002:a62:3201:0:b029:211:3dcc:c9ca with SMTP id y1-20020a6232010000b02902113dccc9camr492134pfy.46.1618443264202; Wed, 14 Apr 2021 16:34:24 -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: erdemaktas@google.com Date: Wed, 14 Apr 2021 16:34:13 -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: 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 , Paolo Bonzini , Nathaniel McCallum Content-Type: text/plain; charset="UTF-8" Hi all, >>Can we please pry a little bit at that "one binary" requirement? I think when we call it a "one binary" requirement, it sounds like we are asking something new but what we are asking is pretty much captured by James Bottomley. We do not want to generate different binaries for AMD, Intel, Intel with TDX, AMD with SEV/SNP etc therefore we were expecting the TDX changes to be part of the upstream code. Of course there can be tuning or customization for specific use cases but those are all future and product specific questions. I just do not see the reason why the upstreamed code should have a limitation of not being able to generate a single binary for the same architecture. -Erdem On Mon, Apr 12, 2021 at 7:34 AM James Bottomley wrote: > > On Mon, 2021-04-12 at 11:54 +0000, Yao, Jiewen wrote: > > I totally agree with you that from security perspective, the best > > idea to isolate AMD SEV/Intel TDX from standard OVMF. > > There's a big difference between building tuned binaries and separating > the subsystems entirely. Ideally we don't want customers running > images to have to build them differently for Intel or AMD (a bit like > how QEMU/KVM hide the VM differences from users), and Confidential > Computing shares a huge amount of interface similarity, so we wouldn't > want that separated. I think the rule should be that if both Intel and > AMD expose a feature in different ways, OVMF tries to expose a uniform > API for that feature over two differing implementations. > > > Do you want to propose move AMD SEV support to another SEC? > > You mean have an entirely separate SEC for AMD, OVMF and Intel? I > really wouldn't do that: much that's in the SEC: page table setup, > memory mapping and decompression is common to all of them. This all > follows for a lot of the components. > > To build separate binaries, we just need separate dsc and fdf files. > Then I think the goal would be to share as much as possible to avoid > duplicating the maintenance and possibly diverging the user API. > > James > > > > > > >