Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230113212926.2904735-1-dionnaglaze@google.com>
 <20230113222024.rp2erl54vx3grdbd@box.shutemov.name> <20230116105648.63hsxnmj2juwudmu@sirius.home.kraxel.org>
 <def9b0b5-b880-be99-fa95-b05d76a91824@intel.com> <1818a72f-31ef-07b0-d1b4-6a8904636db2@amd.com>
In-Reply-To: <1818a72f-31ef-07b0-d1b4-6a8904636db2@amd.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Wed, 18 Jan 2023 16:09:18 +0100
Message-ID: <CAMj1kXG7s_B1nyEgsxFRRvUzsWNXcFfTszRA2hKY=_a-L24PZg@mail.gmail.com>
Subject: Re: [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI
To:     Tom Lendacky <thomas.lendacky@amd.com>,
        Matthew Garrett <mjg59@srcf.ucam.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Borislav Petkov <bp@alien8.de>
Cc:     Dave Hansen <dave.hansen@intel.com>,
        Gerd Hoffmann <kraxel@redhat.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Dionna Glaze <dionnaglaze@google.com>,
        linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
        x86@kernel.org, jiewen.yao@intel.com, devel@edk2.groups.io,
        "Min M. Xu" <min.m.xu@intel.org>,
        James Bottomley <jejb@linux.ibm.com>,
        Erdem Aktas <erdemaktas@google.com>,
        Dave Hansen <dave.hansen@linux.intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

(cc'ing some folks whom I've discussed this with off-list today)

Full discussion here:
https://lore.kernel.org/linux-efi/20230113212926.2904735-1-dionnaglaze@google.com/

On Mon, 16 Jan 2023 at 23:46, Tom Lendacky <thomas.lendacky@amd.com> wrote:
>
> On 1/16/23 15:22, Dave Hansen wrote:
> > On 1/16/23 02:56, Gerd Hoffmann wrote:
> >>> And we add this protocol to address very temporary problem: once
> >>> unaccepted memory support get upstream it is just a dead weight.
> >> Maybe, maybe not.  unaccepted memory support has a Kconfig switch after
> >> all.  If we figure in 3-5 years that all distros have enabled it anyway
> >> we can drop it again.  For the transition period it will surely be
> >> useful.
> >
> > I agree with Kirill here.
> >
> > Having unaccepted memory *AND* this firmware-driven feature really is
> > just implementing the same thing twice.
>
> I'm not sure I follow you. This feature merely tells the firmware whether
> or not the OS supports unaccepted memory, which then tells the firmware
> whether it needs to accept the memory or whether the kernel can.
>
> We have had SNP guest support since 5.19 without support for unaccepted
> memory. Imagine now using a newer OVMF that can support unaccepted memory.
> How does the firmware know whether it must accept all the memory or
> whether it can advertise unaccepted memory. By having the kernel call this
> boot service protocol once support for unaccepted memory is in place, the
> firmware now knows that it need not accept all the memory.
>

So if people deploying SEV agree that this is a useful feature to
have, and people working on TDX saying this protocol must never exist,
I think the obvious conclusion is that OVMF should only expose it when
running on SEV.

However, I am still failing to grasp why there is disagreement here.
Linux already implements SEV support but unaccepted memory protocol is
not supported yet, and so it is crystal clear that we need something
to bridge the compatibility gap. Without this protocol, firmware must
never accept memory, and the OS must always take charge of this, even
if it prefers to accept memory eagerly.

With this protocol in place, acceptance becomes a policy decision,
where the default policy is 'accept' for OS implementations that have
no understanding of unaccepted memory or the protocol. 'Enlightened'
OSes can still decide not to call the protocol and therefore not
having to bother with acceptance at all, given that the firmware will
take care of it.

As for the 'legacy' boot method: this bootloader can decide for itself
whether or not it needs to invoke the protocol, and can invent its own
methods for communicating/inspecting the OS image to obtain the
information to base this decision on. This is outside of the scope of
EFI. However, I also disagree with the binary 'no solution shall
exist' vs 'a solution must cover every imaginable combination of
bootloader and OS image': it makes sense to be pragmatic here, and
limit ourselves to what people are actually deploying. And given the
default behavior fo 'accept everything', the only penalty for ignoring
the legacy bootloader case is a slower boot.

I have been on the sidelines for most of the OVMF and Linux
development regarding confidential compute, but where I did get
involved, it was to try and reach consensus between the different
technologies (including the ARM one), to avoid ending up with radical
different approaches for doing the same thing.

However, I guess we're at a point where SEV and TDX really want
different solutions, so I think divergence might be the way to
proceed.