From: Alistair Popple <apopple@nvidia.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Dan Williams <dan.j.williams@intel.com>,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, max8rr8@gmail.com,
linux-kernel@vger.kernel.org, x86@kernel.org,
jhubbard@nvidia.com, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 1/1] x86/ioremap: Use is_vmalloc_addr in iounmap
Date: Mon, 12 Aug 2024 21:46:40 +1000 [thread overview]
Message-ID: <87frra3qlr.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <87ikw6rrau.ffs@tglx>
Thomas Gleixner <tglx@linutronix.de> writes:
> On Mon, Aug 12 2024 at 17:41, Alistair Popple wrote:
>> Thomas Gleixner <tglx@linutronix.de> writes:
>>> ---
>>> --- a/arch/x86/include/asm/pgtable_64_types.h
>>> +++ b/arch/x86/include/asm/pgtable_64_types.h
>>> @@ -187,6 +187,8 @@ extern unsigned int ptrs_per_p4d;
>>> #define KMSAN_MODULES_ORIGIN_START (KMSAN_MODULES_SHADOW_START + MODULES_LEN)
>>> #endif /* CONFIG_KMSAN */
>>>
>>> +#define DIRECT_MAP_END (VMALLOC_START - 1)
>>
>> If I'm understanding the KASLR implementation correctly then this
>> doesn't seem quite right - the entropy means there is a hole from the
>> end of the direct map (ie. the range PAGE_OFFSET to
>> PAGE_OFFSET+kaslr_regions[0].size_tb) and VMALLOC_START which shouldn't
>> be used.
>>
>> In practice hotplugging memory into that range probably works, but it
>> seems like it would set us up for future bugs. It also means memory
>> hotplug could fail intermittently based on the per-boot entropy.
>>
>> For example with CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING set to 10T one
>> could imagine hotplugging 16T would mostly work except on some system
>> boots if KASLR happens to randomly place VMALLOC_START close to the end
>> of the direct map.
>>
>> Therefore to keep memory hotplug deterministic I think it would be
>> better to define DIRECT_MAP_END as a variable that KASLR sets/updates.
>
> Right. I forgot about the hole.
>
>> This does not look right to me - isn't DIRECT_MAP_END a virtual address
>> where as the resource ranges are physical addresses? Ie. I think this
>> should be:
>>
>> + end = min_t(resource_size_t, base->end, __pa(DIRECT_MAP_END));
>>
>> The same applies to the rest of the DIRECT_MAP_END users here. Perhaps
>> it would be better to define this as DIRECT_MAP_SIZE and calculate this
>> based off PAGE_OFFSET instead?
>
> Duh, yes. I shouldn't try to write patches at 30C :)
It's a much more plesent 7C in the upside down half of the world atm :)
Anyway I will put together a proper patch to do the above.
next prev parent reply other threads:[~2024-08-12 11:52 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-10 10:00 [PATCH 1/1] x86/ioremap: Use is_vmalloc_addr in iounmap Max Ramanouski
2024-08-08 6:12 ` Alistair Popple
2024-08-08 6:44 ` John Hubbard
2024-08-12 6:15 ` Christoph Hellwig
2024-08-08 14:18 ` Thomas Gleixner
2024-08-08 15:58 ` Dan Williams
2024-08-08 16:15 ` Thomas Gleixner
2024-08-08 16:32 ` Dan Williams
2024-08-08 16:39 ` Dan Williams
2024-08-08 18:44 ` Thomas Gleixner
2024-08-08 19:59 ` Dan Williams
2024-08-09 2:28 ` Alistair Popple
2024-08-09 3:55 ` Dan Williams
2024-08-10 17:45 ` Thomas Gleixner
2024-08-12 7:41 ` Alistair Popple
2024-08-12 10:03 ` Thomas Gleixner
2024-08-12 11:46 ` Alistair Popple [this message]
2024-08-12 12:10 ` Max R
2024-08-12 13:23 ` Thomas Gleixner
2024-08-13 1:33 ` Alistair Popple
2024-08-13 8:20 ` Thomas Gleixner
2024-08-13 20:37 ` Thomas Gleixner
2024-08-13 22:29 ` x86/kaslr: Expose and use the end of the physical memory address space Thomas Gleixner
2024-08-14 0:26 ` Alistair Popple
2024-08-14 14:33 ` Dan Williams
2024-08-15 16:11 ` Kees Cook
2024-08-15 22:48 ` Max R
2024-08-16 9:42 ` David Hildenbrand
2024-08-16 9:43 ` [tip: x86/urgent] " tip-bot2 for Thomas Gleixner
2024-08-20 20:38 ` tip-bot2 for Thomas Gleixner
2024-09-22 22:31 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87frra3qlr.fsf@nvdebian.thelocal \
--to=apopple@nvidia.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jhubbard@nvidia.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=max8rr8@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.