linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Baoquan He <bhe@redhat.com>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	x86@kernel.org, Chao Fan <fanc.fnst@cn.fujitsu.com>,
	linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
	linux-acpi@vger.kernel.org, mingo@redhat.com,
	keescook@chromium.org, rjw@rjwysocki.net, lenb@kernel.org,
	ard.biesheuvel@linaro.org, indou.takao@jp.fujitsu.com,
	caoj.fnst@cn.fujitsu.com
Subject: Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory
Date: Fri, 8 Feb 2019 19:26:00 +0100	[thread overview]
Message-ID: <20190208182600.GJ674@zn.tnic> (raw)
In-Reply-To: <20190205150514.fvztftk75swgfayd@gabell>

On Tue, Feb 05, 2019 at 10:05:16AM -0500, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> Date: Tue, 5 Feb 2019 10:00:59 -0500
> Subject: [PATCH] x86/mm: Introduce adjustment the padding size for KASLR

			"Adjust the padding size for KASLR"

> If the physical memory layout has huge space for hotplug, the padding
> used for the physical memory mapping section is not enough.
> So, such system may crash while memory hot-adding on KASLR enabled system.

Crash why?

Why is the padding not enough?

> For example, SRAT has the following layout, the maximum possible memory
> size is 32TB, and the memory is installed as 2TB actually, then the padding
> size should set 30TB (== possible memory size - actual memory size).
> 
>   SRAT: Node 3 PXM 7 [mem 0x1c0000000000-0x1fffffffffff] hotplug

What is that supposed to exemplify: that range is 3T not 2 and that
range start is not at 2T but 28T. So I have absolutely no clue what
you're trying to explain here.

Please go back, take your time and structure your commit message like
this:

Problem is A.

It happens because of B.

Fix it by doing C.

(Potentially do D).

For more detailed info, see
Documentation/process/submitting-patches.rst, Section "2) Describe your
changes".

> This patch introduces adjustment the padding size if the default

Avoid having "This patch" or "This commit" in the commit message. It is
tautologically useless.

Also, do

$ git grep 'This patch' Documentation/process

for more details.

> padding size isn't enough.
> 
> Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> ---
>  Documentation/x86/zero-page.txt       |  1 +
>  arch/x86/boot/compressed/acpi.c       | 19 +++++++++++++++----
>  arch/x86/include/uapi/asm/bootparam.h |  2 +-
>  arch/x86/mm/kaslr.c                   | 26 +++++++++++++++++++++++++-
>  4 files changed, 42 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
> index 68aed077f..343fe1a90 100644
> --- a/Documentation/x86/zero-page.txt
> +++ b/Documentation/x86/zero-page.txt
> @@ -15,6 +15,7 @@ Offset	Proto	Name		Meaning
>  058/008	ALL	tboot_addr      Physical address of tboot shared page
>  060/010	ALL	ist_info	Intel SpeedStep (IST) BIOS support information
>  				(struct ist_info)
> +078/010	ALL	possible_mem_addr The possible maximum physical memory address.

Why isn't this called max_phys_addr then?

Also, please explain what it means at the end of this file.

>  080/010	ALL	hd0_info	hd0 disk parameter, OBSOLETE!!
>  090/010	ALL	hd1_info	hd1 disk parameter, OBSOLETE!!
>  0A0/010	ALL	sys_desc_table	System description table (struct sys_desc_table),
> diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
> index c5a949335..7dd61b943 100644
> --- a/arch/x86/boot/compressed/acpi.c
> +++ b/arch/x86/boot/compressed/acpi.c
> @@ -288,6 +288,7 @@ int count_immovable_mem_regions(void)
>  	struct acpi_subtable_header *sub_table;
>  	struct acpi_table_header *table_header;
>  	char arg[MAX_ACPI_ARG_LENGTH];
> +	unsigned long long possible_addr, max_possible_addr = 0;
>  	int num = 0;
>  
>  	if (cmdline_find_option("acpi", arg, sizeof(arg)) == 3 &&
> @@ -308,10 +309,19 @@ int count_immovable_mem_regions(void)
>  			struct acpi_srat_mem_affinity *ma;
>  
>  			ma = (struct acpi_srat_mem_affinity *)sub_table;
> -			if (!(ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && ma->length) {
> -				immovable_mem[num].start = ma->base_address;
> -				immovable_mem[num].size = ma->length;
> -				num++;
> +			if (ma->length) {
> +				if (ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) {
> +					possible_addr =
> +						ma->base_address + ma->length;
> +					if (possible_addr > max_possible_addr)
> +						max_possible_addr =
> +							possible_addr;
> +				} else {
> +					immovable_mem[num].start =
> +						ma->base_address;
> +					immovable_mem[num].size = ma->length;
> +					num++;
> +				}

This piece has some ugly linebreaks which makes it impossible to read.
Perhaps because the variable names you're adding are too long.

You can carve it out in a separate function, for example.

>  			if (num >= MAX_NUMNODES*2) {
> @@ -320,6 +330,7 @@ int count_immovable_mem_regions(void)
>  			}
>  		}
>  		table += sub_table->length;
> +		boot_params->possible_mem_addr = max_possible_addr;

This assignment is inside the loop and happens potentially a bunch of
times. Why?

>  	}
>  	return num;
>  }
> diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
> index 60733f137..5b64b606e 100644
> --- a/arch/x86/include/uapi/asm/bootparam.h
> +++ b/arch/x86/include/uapi/asm/bootparam.h
> @@ -156,7 +156,7 @@ struct boot_params {
>  	__u64  tboot_addr;				/* 0x058 */
>  	struct ist_info ist_info;			/* 0x060 */
>  	__u64 acpi_rsdp_addr;				/* 0x070 */
> -	__u8  _pad3[8];					/* 0x078 */
> +	__u64  possible_mem_addr;			/* 0x078 */
>  	__u8  hd0_info[16];	/* obsolete! */		/* 0x080 */
>  	__u8  hd1_info[16];	/* obsolete! */		/* 0x090 */
>  	struct sys_desc_table sys_desc_table; /* obsolete! */	/* 0x0a0 */
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index 3f452ffed..71fc28570 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -70,6 +70,30 @@ static inline bool kaslr_memory_enabled(void)
>  	return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
>  }
>  
> +static unsigned int __init kaslr_padding(void)
> +{
> +	unsigned int rand_mem_physical_padding =
> +				CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +	unsigned long long max_possible_phys, max_actual_phys, threshold;
> +
> +	if (!boot_params.possible_mem_addr)
> +		goto out;
> +
> +	max_actual_phys = roundup(PFN_PHYS(max_pfn), 1ULL << TB_SHIFT);
> +	max_possible_phys = roundup(boot_params.possible_mem_addr,
> +					1ULL << TB_SHIFT);
> +	threshold = max_actual_phys +
> +		((unsigned long long)rand_mem_physical_padding << TB_SHIFT);
> +
> +	if (max_possible_phys > threshold)
> +		rand_mem_physical_padding =
> +			(max_possible_phys - max_actual_phys) >> TB_SHIFT;
> +out:
> +#endif
> +	return rand_mem_physical_padding;

Same problem: local variables with unnecessarily long names make the
code hard to read. Pls shorten.

Also, the types in that function are a total mess. An unsigned int which
you cast to unsigned long long and return an unsigned int again to add
into a sum with unsigned longs. Are you selecting the types randomly?
Why aren't you using plain unsigned longs like the rest of the file does
with memory addresses?

Also, this function could have a comment above it explaining what all
that threshold and actual and possible address arithmetic is supposed to
do.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

  reply	other threads:[~2019-02-08 18:26 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10  8:41 [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory Chao Fan
2018-10-10  8:41 ` [PATCH v8 1/3] x86/boot: Add acpitb.c to parse acpi tables Chao Fan
2018-10-11 10:57   ` Borislav Petkov
2018-10-12  1:56     ` Chao Fan
2018-10-12  9:36     ` Chao Fan
2018-10-12  9:46       ` Borislav Petkov
2018-10-12 10:03         ` Chao Fan
2018-10-16  2:48     ` Chao Fan
2018-10-16 12:40       ` Borislav Petkov
2018-10-17  1:10         ` Chao Fan
2018-10-15 20:26   ` Masayoshi Mizuma
2018-10-16  1:50     ` Chao Fan
2018-10-10  8:41 ` [PATCH v8 2/3] x86/boot/KASLR: Walk srat tables to filter immovable memory Chao Fan
2018-10-10  8:41 ` [PATCH v8 3/3] x86/boot/KASLR: Limit kaslr to choosing the " Chao Fan
2018-10-10  8:59 ` [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in " Borislav Petkov
2018-10-10  9:06   ` Baoquan He
2018-10-10  9:12     ` Chao Fan
2018-10-10  9:21       ` Baoquan He
2018-10-10  9:14     ` Thomas Gleixner
2018-10-10  9:19       ` Borislav Petkov
2018-10-10  9:30         ` Baoquan He
2018-10-10 19:44           ` Masayoshi Mizuma
2018-10-11  0:29             ` Baoquan He
2018-10-11  5:51               ` Chao Fan
2018-10-13 20:19                 ` Masayoshi Mizuma
2018-10-13 20:34                   ` Borislav Petkov
2018-10-13 21:45                     ` Masayoshi Mizuma
2018-10-13 22:05                       ` Borislav Petkov
2018-10-15  0:50                         ` Masayoshi Mizuma
2018-10-16 15:13                           ` Masayoshi Mizuma
2018-10-16 19:11                             ` Borislav Petkov
2018-10-16 19:54                               ` Masayoshi Mizuma
2018-10-16 19:59                                 ` Borislav Petkov
2018-10-22 15:42                                   ` Masayoshi Mizuma
2018-10-23  2:48                                     ` Chao Fan
2018-10-24 19:21                                       ` Masayoshi Mizuma
2018-10-25  1:22                                         ` Chao Fan
2018-10-25 10:33                                     ` Borislav Petkov
2018-10-25 13:40                                       ` Masayoshi Mizuma
2018-11-06 12:10                                         ` Borislav Petkov
2018-11-06 14:07                                           ` Baoquan He
2018-11-07  1:21                                             ` Chao Fan
2018-11-06 18:45                                         ` Borislav Petkov
2018-11-06 19:36                                           ` Masayoshi Mizuma
2018-11-06 20:45                                             ` Borislav Petkov
2018-11-06 22:21                                               ` Masayoshi Mizuma
2018-11-08 10:51                                                 ` Borislav Petkov
2018-11-10 10:54                                                   ` Borislav Petkov
2018-11-11 13:45                                                     ` Masayoshi Mizuma
2019-02-05 15:05                                                       ` Masayoshi Mizuma
2019-02-08 18:26                                                         ` Borislav Petkov [this message]
2019-02-09  0:24                                                           ` Masayoshi Mizuma
2019-02-11  1:46                                                         ` Chao Fan
2019-02-11 20:11                                                           ` Masayoshi Mizuma
2018-10-10 17:16 ` Borislav Petkov
2018-10-11  1:30   ` Chao Fan

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=20190208182600.GJ674@zn.tnic \
    --to=bp@alien8.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bhe@redhat.com \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=fanc.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=indou.takao@jp.fujitsu.com \
    --cc=keescook@chromium.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=msys.mizuma@gmail.com \
    --cc=rjw@rjwysocki.net \
    --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).