linux-kernel - Re: [PATCHv10 04/11] efi/x86: Implement support for unaccepted memory

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: <20230512105919.lgy3cvio6m2vcygn@box.shutemov.name>
Date:   Fri, 12 May 2023 13:59:19 +0300
From:   "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     "Kirill A. Shutemov" <kirill@...temov.name>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Joerg Roedel <jroedel@...e.de>,
        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>,
        Dario Faggioli <dfaggioli@...e.com>,
        Mike Rapoport <rppt@...nel.org>,
        David Hildenbrand <david@...hat.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        marcelo.cerri@...onical.com, tim.gardner@...onical.com,
        khalid.elmously@...onical.com, philip.cox@...onical.com,
        aarcange@...hat.com, peterx@...hat.com, x86@...nel.org,
        linux-mm@...ck.org, linux-coco@...ts.linux.dev,
        linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv10 04/11] efi/x86: Implement support for unaccepted memory

On Fri, May 12, 2023 at 09:39:30AM +0200, Ard Biesheuvel wrote:
> Please replace PMD_SIZE with something along the lines of
> EFI_UNACCEPTED_UNIT_SIZE and #define it to PMD_SIZE in
> arch/x86/include/asm/efi.h.
> 
> The comment below about the size of the bitmap vs the size of the
> address space should probably move there as well.

Okay, will do.

> > +void accept_memory(phys_addr_t start, phys_addr_t end)
> > +{
> > +       unsigned long range_start, range_end;
> > +       unsigned long bitmap_size;
> > +       u64 unit_size;
> > +
> > +       if (!unaccepted_table)
> > +               return;
> > +
> > +       unit_size = unaccepted_table->unit_size;
> > +
> > +       /*
> > +        * Only care for the part of the range that is represented
> > +        * in the bitmap.
> > +        */
> > +       if (start < unaccepted_table->phys_base)
> > +               start = unaccepted_table->phys_base;
> > +       if (end < unaccepted_table->phys_base)
> > +               return;
> > +
> > +       /* Translate to offsets from the beginning of the bitmap */
> > +       start -= unaccepted_table->phys_base;
> > +       end -= unaccepted_table->phys_base;
> > +
> > +       /* Make sure not to overrun the bitmap */
> > +       if (end > unaccepted_table->size * unit_size * BITS_PER_BYTE)
> > +               end = unaccepted_table->size * unit_size * BITS_PER_BYTE;
> > +
> 
> Should we warn here?

No. accept_memory() is nop for conventional memory (memblock calls it
unconditionally).

With the fixup, we only allocate bitmap for the range of physical address
space where we have unaccepted memory. So if there's conventional memory
after unaccepted, bitmap will not cover it.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov