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: <PH0PR11MB5064B561086BE6350CC1DCDCC5CF9@PH0PR11MB5064.namprd11.prod.outlook.com>
Date:   Mon, 16 May 2022 06:46:53 +0000
From:   "Xu, Min M" <min.m.xu@...el.com>
To:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Borislav Petkov <bp@...e.de>,
        "Gao, Jiaqi" <jiaqi.gao@...el.com>
CC:     Dionna Amalie Glaze <dionnaglaze@...gle.com>,
        Michael Roth <michael.roth@....com>,
        Borislav Petkov <bp@...en8.de>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Rodel, Jorg" <jroedel@...e.de>, Ard Biesheuvel <ardb@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        "Kuppuswamy Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        David Rientjes <rientjes@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Tom Lendacky <thomas.lendacky@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Peter Zijlstra" <peterz@...radead.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        "Ingo Molnar" <mingo@...hat.com>,
        Varad Gautam <varad.gautam@...e.com>,
        "Dario Faggioli" <dfaggioli@...e.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Mike Rapoport" <rppt@...nel.org>,
        David Hildenbrand <david@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory

On May 13, 2022 10:45 PM, Kirill A. Shutemov wrote:
> On Fri, May 13, 2022 at 11:01:43AM +0200, Borislav Petkov wrote:
> > + mroth
> > - brijesh
> >
> > On Thu, May 12, 2022 at 10:34:02PM -0700, Dionna Amalie Glaze wrote:
> > > Kirill, I've been tracking these changes to see if we can handle the
> > > unaccepted memory type for SEV-SNP, but testing has been an issue.
> > > The proposed patch in Ovmf to introduce unaccepted memory seems to
> > > have stalled out last September
> > > (https://www.mail-archive.com/devel@edk2.groups.io/msg35842.html)
> > > and is particularly difficult to adapt to SEV-SNP since it doesn't
> > > follow the TDVF way of initializing all memory. Is there a different
> > > development I might have missed so that we might test these cases?
> > > Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any
> kernel
> > > uses are essentially dead code.
> 
> + Min, Jiaqi.
> 
> I don't follow firmware development. Min, Jiaqi, could you comment?
> 
We have prepared the patch for unaccepted memory and it is now working in our internal release.
But there is an obstacle to upstream it to edk2 master branch. 
The patch-set depends on the definition of UEFI_RESOURCE_MEMORY_UNACCEPTED in PI spec. This is proposed in https://github.com/microsoft/mu_basecore/pull/66/files#diff-b20a11152d1ce9249c691be5690b4baf52069efadf2e2546cdd2eb663d80c9e4R237, according to UEFI-Code-First. The proposal was approved in 2021 in UEFI Mantis, and will be added to the new PI.next specification. (Till now it has not been added in the latest PI spec.)
So UEFI_RESOURCE_MEMORY_UNACCEPTED cannot be added in MdePkg which make it difficult to submit the patch to edk2 community for review. See this link: https://edk2.groups.io/g/devel/message/87558

Please be noted: UEFI_RESOURCE_MEMORY_UNACCEPTED (defined in PI spec) is different from EFI_UNACCEPTED_MEMORY (defined in UEFI spec)

I will submit the patch-set once the new definition is added in the new PI.next spec.

Thanks
Min

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ