linux-kernel - Re: [PATCH v7 6/6] 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]

Message-ID: <ts3dltyfxkchkop3y6uenz34bghyg2phwmlxxbigxi3b7nzy3d@b7a6a57ogpm2>
Date:   Wed, 5 Apr 2023 12:06:05 +0200
From:   Gerd Hoffmann <kraxel@...hat.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Michael Roth <michael.roth@....com>,
        Joerg Roedel <jroedel@...e.de>,
        Dionna Glaze <dionnaglaze@...gle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Min M. Xu" <min.m.xu@...el.com>,
        James Bottomley <jejb@...ux.ibm.com>,
        Jiewen Yao <jiewen.yao@...el.com>,
        Erdem Aktas <erdemaktas@...gle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH v7 6/6] x86/efi: Safely enable unaccepted memory in UEFI

  Hi,

> User will specify if it wants unaccepted memory or not for the VM. And if
> it does it is his responsibility to have kernel that supports it.
> 
> And you have not addressed my question:
> 
> 	How is it different from any other feature the kernel is not [yet] aware
> 	of?

Come on.  Automatic feature negotiation is standard procedure in many
places.  It's not like we inventing something totally new here.

Just one example:  When a virtio device learns a new trick a feature flag
is added for it, and in case both guest and host support it it can be
enabled, otherwise not.  There is no need for the user to configure the
virtio device features manually according to the capabilities of the
kernel it is going to boot.

take care,
  Gerd