linux-kernel - Re: [PATCH 2/5] 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: <6cf6199c-3c3f-3f36-5570-eadfadb89b30@intel.com>
Date:   Thu, 12 Aug 2021 14:43:19 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>,
        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>,
        Varad Gautam <varad.gautam@...e.com>,
        Dario Faggioli <dfaggioli@...e.com>, x86@...nel.org,
        linux-mm@...ck.org, linux-coco@...ts.linux.dev,
        linux-kernel@...r.kernel.org,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH 2/5] efi/x86: Implement support for unaccepted memory

On 8/12/21 2:14 PM, Kirill A. Shutemov wrote:
> On Tue, Aug 10, 2021 at 10:50:33AM -0700, Dave Hansen wrote:
>>> +	if ((start & PMD_MASK) == (end & PMD_MASK)) {
>>> +		npages = (end - start) / PAGE_SIZE;
>>> +		__accept_memory(start, start + npages * PAGE_SIZE);
>>> +		return;
>>> +	}
>>
>> Hmm, is it possible to have this case hit, but neither of the two below
>> cases?  This seems to be looking for a case where the range is somehow
>> entirely contained in one PMD_SIZE area, but where it doesn't consume a
>> whole area.
>>
>> Wouldn't that mean that 'start' or 'end' must be unaligned?
> 
> The problem is that if both of them unaligned round_up() and round_down()
> in the cases below would step outside the requested range.

Ahh, got it.

You might want to add some comments like:

	/* Immediately accept whole thing if within a PMD_SIZE block: */

	/* Immediately accept a <PMD_SIZE piece at the start: */

	/* Immediately accept a <PMD_SIZE piece at the end: */

	/* Mark full PMD_SIZE areas so they can be accepted later */

To the three if statements and the bitmap_set().

After looking at this, I do think you probably did this the simplest way
possible.  It just needs a little help.

>>> +	if (start & ~PMD_MASK) {
>>> +		npages = (round_up(start, PMD_SIZE) - start) / PAGE_SIZE;
>>> +		__accept_memory(start, start + npages * PAGE_SIZE);
>>> +		start = round_up(start, PMD_SIZE);
>>> +	}
>>> +
>>> +	if (end & ~PMD_MASK) {
>>> +		npages = (end - round_down(end, PMD_SIZE)) / PAGE_SIZE;
>>> +		end = round_down(end, PMD_SIZE);
>>> +		__accept_memory(end, end + npages * PAGE_SIZE);
>>> +	}
>>> +	npages = (end - start) / PMD_SIZE;
>>> +	bitmap_set((unsigned long *)params->unaccepted_memory,
>>> +		   start / PMD_SIZE, npages);
>>> +}

One note as I'm looking at this again: 'npages' can be 0.  Imagine if
you had an 8k region that started with the last 4k page of a 2M area and
ended on the first 4k page of the next 2M area, like 0x1ff000->0x201000.

I think it's harmless and bitmap_set() seems to handle it correctly.
But, it's probably worth a comment because it's not obvious.