All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
	mingo@kernel.org, hpa@zytor.com, kirill@shutemov.name,
	keescook@chromium.org, peterz@infradead.org, thgarnie@google.com,
	herbert@gondor.apana.org.au, mike.travis@hpe.com,
	frank.ramsay@hpe.com, yamada.masahiro@socionext.com
Subject: Re: [PATCH v2 RESEND 1/2] x86/mm/KASLR: Fix the size of the direct mapping section
Date: Wed, 17 Apr 2019 16:35:36 +0800	[thread overview]
Message-ID: <20190417083536.GE7065@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20190415185319.GI29317@zn.tnic>

On 04/15/19 at 08:53pm, Borislav Petkov wrote:
> Now, lemme make sure I understand exactly what you're fixing here:
> you're fixing the case where CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING is
> not 0. Which is the case when CONFIG_MEMORY_HOTPLUG is enabled.
> 
> Yes, no?

Yes, the padding is reserved specifically for possible furture memory
hotplugging.
> 
> If so, please extend the commit message with that fact because it is
> crucial and the last missing piece in the explanation.
> 
> Otherwise, when the padding is 0, the clamping:
> 
>         /* Adapt phyiscal memory region size based on available memory */
>         if (memory_tb < kaslr_regions[0].size_tb)
>                 kaslr_regions[0].size_tb = memory_tb;
> 
> will "fix" the direct mapping section size.

I made a new one to add this fact, I can repost if it's OK to you.
Thanks.

From 6f0fdb9df6acdcd42b8cbdecaf5058c3090fd577 Mon Sep 17 00:00:00 2001
From: Baoquan He <bhe@redhat.com>
Date: Thu, 4 Apr 2019 10:03:13 +0800
Subject: [PATCH] x86/mm/KASLR: Fix the size of the direct mapping section

kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate
the maximum amount of system RAM supported. The size of the direct
mapping section is obtained from the smaller one of the below two
values:

 (actual system RAM size + padding size) vs (max system RAM size supported)

This calculation is wrong since commit:
b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52").

In commit b83ce5ee91471d, __PHYSICAL_MASK_SHIFT was changed to be 52,
regardless of whether it's using 4-level or 5-level page tables.
It will always use 4 PB as the maximum amount of system RAM, even
in 4-level paging mode where it should be 64 TB.  Thus the size of
the direct mapping section will always be the sum of the actual
system RAM size plus the padding size.

Even when the amount of system RAM is 64 TB, the following layout will
still be used. Obviously KALSR will be weakened significantly.

   |____|_______actual RAM_______|_padding_|______the rest_______|
   0            64TB                                            ~120TB

What we want is the following:

   |____|_______actual RAM_______|_________the rest______________|
   0            64TB                                            ~120TB

Here, the size of padding region can be configured with
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, 10 TB by default. The above
issue only exists when CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING is set
to a non-zero value. Otherwise, using __PHYSICAL_MASK_SHIFT doesn't
affect KASLR either.

So the code should use MAX_PHYSMEM_BITS instead. Fix it by replacing
__PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.

Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52")
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 78974ee5d97f..4679a0075048 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -95,7 +95,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.17.2


  reply	other threads:[~2019-04-17  8:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-14  7:28 [PATCH v2 RESEND 0/2] x86/mm/KASLR: Fix the wrong size of memory sections Baoquan He
2019-04-14  7:28 ` [PATCH v2 RESEND 1/2] x86/mm/KASLR: Fix the size of the direct mapping section Baoquan He
2019-04-15 18:53   ` Borislav Petkov
2019-04-17  8:35     ` Baoquan He [this message]
2019-04-17 15:01       ` Borislav Petkov
2019-04-17 22:42         ` Baoquan He
2019-04-18  8:52       ` [tip:x86/urgent] " tip-bot for Baoquan He
2019-04-14  7:28 ` [PATCH v2 RESEND 2/2] x86/mm/KASLR: Fix the size of vmemmap section Baoquan He
2019-04-15 19:47   ` Borislav Petkov
2019-04-17  8:39     ` Baoquan He
2019-04-26  9:23     ` Baoquan He
2019-04-26 10:04       ` Borislav Petkov
2019-04-26 10:18         ` Baoquan He
2019-04-22  9:10   ` [PATCH v3 " Baoquan He
2019-04-22  9:14     ` Baoquan He
2019-04-28 18:54     ` Kirill A. Shutemov
2019-04-29  8:12       ` Baoquan He
2019-04-29 13:16         ` Kirill A. Shutemov

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=20190417083536.GE7065@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=frank.ramsay@hpe.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.travis@hpe.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=x86@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    --subject='Re: [PATCH v2 RESEND 1/2] x86/mm/KASLR: Fix the size of the direct mapping section' \
    /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

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.