From: Baoquan He <bhe@redhat.com>
To: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 4/4] x86/mm/KASLR: Adjust the padding size for the direct mapping.
Date: Sun, 17 Nov 2019 08:42:16 +0800 [thread overview]
Message-ID: <20191117004216.GN30906@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20191115144917.28469-5-msys.mizuma@gmail.com>
On 11/15/19 at 09:49am, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>
> The system sometimes crashes while memory hot-adding on KASLR
> enabled system. The crash happens because the regions pointed by
> kaslr_regions[].base are overwritten by the hot-added memory.
>
> It happens because of the padding size for kaslr_regions[].base isn't
> enough for the system whose physical memory layout has huge space for
> memory hotplug. kaslr_regions[].base points "actual installed
> memory size + padding" or higher address. So, if the "actual + padding"
> is lower address than the maximum memory address, which means the memory
> address reachable by memory hot-add, kaslr_regions[].base is destroyed by
> the overwritten.
>
> address
> ^
> |------- maximum memory address (Hotplug)
> | ^
> |------- kaslr_regions[0].base | Hotadd-able region
> | ^ |
> | | padding |
> | V V
> |------- actual memory address (Installed on boot)
> |
>
> Fix it by getting the maximum memory address from SRAT and store
> the value in boot_param, then set the padding size while KASLR
> initializing if the default padding size isn't enough.
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
> Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> ---
> arch/x86/mm/kaslr.c | 57 +++++++++++++++++++++++++++++++++------------
> 1 file changed, 42 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index dc6182eecefa..1f0aa9e68226 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -70,15 +70,52 @@ static inline bool kaslr_memory_enabled(void)
> return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
> }
>
> +/*
> + * Even though a huge virtual address space is reserved for the direct
> + * mapping of physical memory, e.g in 4-level paging mode, it's 64TB,
> + * rare system can own enough physical memory to use it up, most are
> + * even less than 1TB. So with KASLR enabled, we adapt the size of
> + * direct mapping area to the size of actual physical memory plus the
> + * configured padding CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING.
> + * The left part will be taken out to join memory randomization.
The doc doesn't reflect the the case of boot_params.max_addr existed?
Otherwise, it looks good to me and easy to understand. You can remove my
'Signed-off' and feel free to add my ack.
Acked-by: Baoquan He <bhe@redhat.com>
Thanks
Baoquan
> + */
> +static inline unsigned long calc_direct_mapping_size(void)
> +{
> + unsigned long size_tb, memory_tb;
> +
> + memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
> + CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
> +
> +#ifdef CONFIG_MEMORY_HOTPLUG
> + if (boot_params.max_addr) {
> + unsigned long maximum_tb;
> +
> + maximum_tb = DIV_ROUND_UP(boot_params.max_addr,
> + 1UL << TB_SHIFT);
> +
> + if (maximum_tb > memory_tb)
> + memory_tb = maximum_tb;
> + }
> +#endif
> + size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
> +
> + /*
> + * Adapt physical memory region size based on available memory
> + */
> + if (memory_tb < size_tb)
> + size_tb = memory_tb;
> +
> + return size_tb;
> +}
> +
> /* Initialize base and padding for each memory region randomized with KASLR */
> void __init kernel_randomize_memory(void)
> {
> - size_t i;
> - unsigned long vaddr_start, vaddr;
> - unsigned long rand, memory_tb;
> - struct rnd_state rand_state;
> + unsigned long vaddr_start, vaddr, rand;
> unsigned long remain_entropy;
> unsigned long vmemmap_size;
> + struct rnd_state rand_state;
> + size_t i;
>
> vaddr_start = pgtable_l5_enabled() ? __PAGE_OFFSET_BASE_L5 : __PAGE_OFFSET_BASE_L4;
> vaddr = vaddr_start;
> @@ -95,20 +132,10 @@ void __init kernel_randomize_memory(void)
> if (!kaslr_memory_enabled())
> return;
>
> - kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
> + kaslr_regions[0].size_tb = calc_direct_mapping_size();
> kaslr_regions[1].size_tb = VMALLOC_SIZE_TB;
>
> - /*
> - * Update Physical memory mapping to available and
> - * add padding if needed (especially for memory hotplug support).
> - */
> BUG_ON(kaslr_regions[0].base != &page_offset_base);
> - memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
> - CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
> -
> - /* Adapt phyiscal memory region size based on available memory */
> - if (memory_tb < kaslr_regions[0].size_tb)
> - kaslr_regions[0].size_tb = memory_tb;
>
> /*
> * Calculate the vmemmap region size in TBs, aligned to a TB
> --
> 2.20.1
>
next prev parent reply other threads:[~2019-11-17 0:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 14:49 [PATCH v5 0/4] Adjust the padding size for KASLR Masayoshi Mizuma
2019-11-15 14:49 ` [PATCH v5 1/4] x86/boot: Wrap up the SRAT traversing code into subtable_parse() Masayoshi Mizuma
2019-12-12 20:18 ` Borislav Petkov
2019-11-15 14:49 ` [PATCH v5 2/4] x86/boot: Add max_addr field in struct boot_params Masayoshi Mizuma
2019-11-15 14:49 ` [PATCH v5 3/4] x86/boot: Get the max address from SRAT Masayoshi Mizuma
2019-11-15 14:49 ` [PATCH v5 4/4] x86/mm/KASLR: Adjust the padding size for the direct mapping Masayoshi Mizuma
2019-11-17 0:42 ` Baoquan He [this message]
2019-12-12 20:19 ` Borislav Petkov
2019-12-13 13:28 ` Baoquan He
2019-12-13 14:15 ` Borislav Petkov
2019-12-13 14:54 ` Baoquan He
2019-12-13 16:38 ` Borislav Petkov
2019-12-13 23:29 ` Baoquan He
2019-12-14 7:13 ` Borislav Petkov
2019-12-14 10:07 ` Baoquan He
2019-12-14 3:33 ` Baoquan He
2019-12-14 7:15 ` Borislav Petkov
2019-12-12 20:17 ` [PATCH v5 0/4] Adjust the padding size for KASLR Borislav Petkov
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=20191117004216.GN30906@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.mizuma@jp.fujitsu.com \
--cc=mingo@redhat.com \
--cc=msys.mizuma@gmail.com \
--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.