linux-kernel - Re: [PATCH v5 4/4] x86/mm/KASLR: Adjust the padding size for the direct mapping.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 14 Dec 2019 11:33:48 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Masayoshi Mizuma <msys.mizuma@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Masayoshi Mizuma <m.mizuma@...fujitsu.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 4/4] x86/mm/KASLR: Adjust the padding size for the
 direct mapping.

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