linux-kernel - Re: [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Jan 2023 16:46:32 -0600
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Dave Hansen <dave.hansen@...el.com>,
        Gerd Hoffmann <kraxel@...hat.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc:     Dionna Glaze <dionnaglaze@...gle.com>,
        linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
        x86@...nel.org, jiewen.yao@...el.com, devel@...2.groups.io,
        Ard Biescheuvel <ardb@...nel.org>,
        "Min M. Xu" <min.m.xu@...el.org>,
        James Bottomley <jejb@...ux.ibm.com>,
        Erdem Aktas <erdemaktas@...gle.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI

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.

Thanks,
Tom

> 
> I'd much rather have the Kconfig option forced on for all guests that
> *might* need unaccepted memory support than carry redundant implementations.
> 
> Also, _if_ we allow folks to turn the Kconfig off and get access to all
> their memory, they might get used to that.  Removing this firmware
> interface from the kernel in a few years could be viewed as a
> regression.  Then, we'll be stuck with this forever.
> 
> In any case, the firmware side of things didn't seem like _that_ much
> code.  So, I'm not protesting *that* strongly.  But, I also don't
> believe for a second that this is going to be removed in 3-5 years.