From: Baoquan He <bhe@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: tglx@linutronix.de, hpa@zytor.com, thgarnie@google.com,
kirill.shutemov@linux.intel.com, x86@kernel.org,
linux-kernel@vger.kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH v2 1/3] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size
Date: Tue, 11 Sep 2018 15:22:09 +0800 [thread overview]
Message-ID: <20180911072209.GV1740@192.168.1.3> (raw)
In-Reply-To: <20180910061839.GA90334@gmail.com>
On 09/10/18 at 08:18am, Ingo Molnar wrote:
>
> * Baoquan He <bhe@redhat.com> wrote:
>
> > In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the
> > initial size of the direct mapping region. This is right in the
> > old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS,
> > 46bit, and only 4-level mode was supported.
>......
> - what does 'memory KASLR' mean? All KASLR deals with memory.
Thanks for your reviewing. I have updated patch log according to your
comments. For this one, Thomas Garnier calls it memory section KASLR, to
differentiate with kernel text KASLR. I would like to call it memory region
KASLR, is it OK?
Paste the updated patch here.
From df0df638a24aafeee6862f184769c4fb96f29afb Mon Sep 17 00:00:00 2001
From: Baoquan He <bhe@redhat.com>
Date: Fri, 29 Jun 2018 09:43:28 +0800
Subject: [PATCH] x86/mm/KASLR: Fix the wrong calculation of memory region
initial size
In memory region KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate
the initial size of the direct mapping region. This is correct in
the old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS,
46 bits, and only 4-level mode was supported.
Later, in commit:
b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"),
__PHYSICAL_MASK_SHIFT was changed to be always 52 bits, no matter it's
5-level or 4-level. This is wrong for 4-level paging. Then when we
adapt physical memory region size based on available memory, it
will overflow if the amount of system RAM and the padding is bigger
than 64 TB.
In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by
replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Thomas Garnier <thgarnie@google.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
---
arch/x86/mm/kaslr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 61db77b0eda9..0988971069c9 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -93,7 +93,7 @@ void __init kernel_randomize_memory(void)
if (!kaslr_memory_enabled())
return;
- kaslr_regions[0].size_tb = 1 << (__PHYSICAL_MASK_SHIFT - TB_SHIFT);
+ kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
kaslr_regions[1].size_tb = VMALLOC_SIZE_TB;
/*
--
2.13.6
prev parent reply other threads:[~2018-09-11 7:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-09 12:49 Baoquan He
2018-09-09 12:49 ` [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region Baoquan He
2018-09-10 6:11 ` Ingo Molnar
2018-09-11 7:30 ` Baoquan He
2018-09-11 7:59 ` Ingo Molnar
2018-09-11 8:18 ` Baoquan He
2018-09-11 9:28 ` Ingo Molnar
2018-09-11 12:08 ` Baoquan He
2018-09-12 3:18 ` Baoquan He
2018-09-12 6:31 ` Ingo Molnar
2018-09-12 9:41 ` Baoquan He
2018-09-12 10:01 ` Ingo Molnar
2018-09-21 2:10 ` Baoquan He
2018-09-09 12:49 ` [PATCH v2 3/3] mm: Add build time sanity chcek for struct page size Baoquan He
2018-09-10 13:41 ` kbuild test robot
2018-09-11 7:47 ` Baoquan He
2018-09-10 6:18 ` [PATCH v2 1/3] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size Ingo Molnar
2018-09-11 7:22 ` Baoquan He [this message]
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=20180911072209.GV1740@192.168.1.3 \
--to=bhe@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome