linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>,
	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: Sat, 14 Dec 2019 11:33:48 +0800	[thread overview]
Message-ID: <20191214033348.GJ28917@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20191212201916.GL4991@zn.tnic>

On 12/12/19 at 09:19pm, Borislav Petkov wrote:
> On Fri, Nov 15, 2019 at 09:49:17AM -0500, Masayoshi Mizuma wrote:
> > +/*
> > + * 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.
> 
> This sentence is unparseable.
> 
> > So with KASLR enabled, we adapt the size of
> 
> Who's "we"?
> 
> > + * 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.
> > + */
> > +static inline unsigned long calc_direct_mapping_size(void)
> 
> What direct mapping?!
> 
> The code is computing the physical memory regions base address and
> sizes.
> 
> > +{
> > +	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);
> 
> All that jumping through hoops and adding a member to boot_params which
> is useless on !hot-add systems - basically the majority out there - just

Read this again, one system owns ACPI SRAT tables, doesn't mean it's
a hot-adding system. Currently, most of systems have ACPI and the
affiliated SRAT tables. But to support memory hotplug, it need specific
firmware setting and web management to remotely power on/off the DIMM.
At least, systems which is delived to us for testing is very few.

So in kernel there's no way to check if memory hotplug is supported in
system. Memory hotplug is the sufficient and unnecessary condition of
the SRAT existence, I would say.

Thanks
Baoquan


  parent reply	other threads:[~2019-12-14  3:34 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
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 [this message]
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=20191214033348.GJ28917@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).