[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3962fe91-4af1-4a85-80a9-b89826d31274@redhat.com>
Date: Fri, 16 Aug 2024 11:42:10 +0200
From: David Hildenbrand <david@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>, Alistair Popple <apopple@...dia.com>
Cc: x86@...nel.org, Dan Williams <dan.j.williams@...el.com>,
dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
max8rr8@...il.com, linux-kernel@...r.kernel.org, jhubbard@...dia.com,
Kees Cook <keescook@...omium.org>, Andrew Morton <akpm@...uxfoundation.org>,
Oscar Salvador <osalvador@...e.de>, linux-mm@...ck.org
Subject: Re: x86/kaslr: Expose and use the end of the physical memory address
space
> MAX_PHYSMEM_BITS cannot be changed for that because the randomization
> does not align with address bit boundaries and there are other places
> which actually require to know the maximum number of address bits. All
> remaining usage sites of MAX_PHYSMEM_BITS have been analyzed and found
> to be correct.
>
Hi Thomas,
> Cure this by exposing the end of the direct map via PHYSMEM_END and use
> that for the memory hot-plug and resource management related places
> instead of relying on MAX_PHYSMEM_BITS. In the KASLR case PHYSMEM_END
> maps to a variable which is initialized by the KASLR initialization and
> otherwise it is based on MAX_PHYSMEM_BITS as before.
Skimming this patch, I got confused why physmem_end is introduced.
I can see a single modification of physmem_end:
physmem_end = ((1ULL << MAX_PHYSMEM_BITS) - 1);
Which is exactly the same as
#ifndef PHYSMEM_END
# define PHYSMEM_END ((1ULL << MAX_PHYSMEM_BITS) - 1)
#endif
And that left me confused why that is required. So we can catch the
transition "physmem_end == 0" -> "physmem_end != 0"?
I'm probably missing something important, so sorry for the (likely)
stupid question.
Apart from that, nothing jumped at me.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists