All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Fan <fanc.fnst@cn.fujitsu.com>
To: Borislav Petkov <bp@alien8.de>
Cc: <linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
	<keescook@chromium.org>, <bhe@redhat.com>,
	<msys.mizuma@gmail.com>, <indou.takao@jp.fujitsu.com>,
	<caoj.fnst@cn.fujitsu.com>
Subject: Re: [PATCH v15 3/6] x86/boot: Introduce efi_get_rsdp_addr() to find RSDP from EFI table
Date: Sun, 13 Jan 2019 17:47:04 +0800	[thread overview]
Message-ID: <20190113094704.GC13263@localhost.localdomain> (raw)
In-Reply-To: <20190111103225.GA4729@zn.tnic>

On Fri, Jan 11, 2019 at 11:32:25AM +0100, Borislav Petkov wrote:
>On Fri, Jan 11, 2019 at 09:23:53AM +0800, Chao Fan wrote:
>> Yes, 'table64' looks superfluous here, but after these lines, there is:
>>                         if (!IS_ENABLED(CONFIG_X86_64) && table64 >> 32) {
>> so the 'table64' is useful here for i386. 'table' is unsigned long, it
>> can't do the right shift. But the 'table64' who is u64 can do that right
>> shift.
>
>Have you actually tried fixing what I suggested or you're just talking?

Sure, I tried what I was talking.
I ever used 'unsigned long table' directly. But that caused warning:
  CC      arch/x86/boot/compressed/acpi.o
arch/x86/boot/compressed/acpi.c: In function ‘efi_get_rsdp_addr’:
arch/x86/boot/compressed/acpi.c:106:44: warning: right shift count >= width of type [-Wshift-count-overflow]
    if (!IS_ENABLED(CONFIG_X86_64) && table >> 32) {
To avoid this warning, I add 'u64 table64' to do the right shift.

Well, the acpi_physicall_address defined as:

#if ACPI_MACHINE_WIDTH == 64
typedef u64 acpi_physical_address;
#elif ACPI_MACHINE_WIDTH == 32
#ifdef ACPI_32BIT_PHYSICAL_ADDRESS
typedef u32 acpi_physical_address;
#else                           /* ACPI_32BIT_PHYSICAL_ADDRESS */

/*
 * It is reported that, after some calculations, the physical addresses
can
 * wrap over the 32-bit boundary on 32-bit PAE environment.
 * https://bugzilla.kernel.org/show_bug.cgi?id=87971
 */
typedef u64 acpi_physical_address;
#endif

'acpi_physical_address' could be define as u64 or u32.
In my guest machine, it's defined as u64, there is no problem as you
suggested.
I didn't find a machine where 'acpi_physical_address' defined as u32.
I thought if 'acpi_physical_address' defined as u32, it will meet
the same warning as using 'unsigned long'.
I tried to define 'table' as u32, that will also cause the warning.
So once acpi_physical_address is define as u32, that warning will
happen. We should make sure u64 to do the right shift.

Thanks,
Chao Fan

>
>---
>diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
>index e9dd84f459ed..0537d46fb21f 100644
>--- a/arch/x86/boot/compressed/acpi.c
>+++ b/arch/x86/boot/compressed/acpi.c
>@@ -77,21 +77,19 @@ static acpi_physical_address efi_get_rsdp_addr(void)
> 			sizeof(efi_config_table_32_t);
> 
> 	for (i = 0; i < systab->nr_tables; i++) {
>+		acpi_physical_address table;
> 		void *config_tables;
>-		unsigned long table;
> 		efi_guid_t guid;
> 
> 		config_tables = (void *)(systab->tables + size * i);
> 		if (efi_64) {
> 			efi_config_table_64_t *tmp_table;
>-			u64 table64;
> 
> 			tmp_table = config_tables;
> 			guid = tmp_table->guid;
>-			table64 = tmp_table->table;
>-			table = table64;
>+			table = tmp_table->table;
> 
>-			if (!IS_ENABLED(CONFIG_X86_64) && table64 >> 32) {
>+			if (!IS_ENABLED(CONFIG_X86_64) && table >> 32) {
> 				debug_putstr("Error getting RSDP address: EFI config table located above 4GB.\n");
> 				return 0;
> 			}
>
>-- 
>Regards/Gruss,
>    Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.
>
>



  reply	other threads:[~2019-01-13  9:48 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-07  3:22 [PATCH v15 0/6] x86/boot/KASLR: Parse ACPI table and limit KASLR to choosing immovable memory Chao Fan
2019-01-07  3:22 ` [PATCH v15 1/6] x86/boot: Copy kstrtoull() to boot/string.c instead of using simple_strtoull() Chao Fan
2019-01-09 12:48   ` Borislav Petkov
2019-01-10  1:15     ` Chao Fan
2019-01-07  3:22 ` [PATCH v15 2/6] x86/boot: Introduce get_acpi_rsdp() to parse RSDP in cmdline from KEXEC Chao Fan
2019-01-10 17:01   ` Borislav Petkov
2019-01-11  1:17     ` Chao Fan
2019-01-07  3:22 ` [PATCH v15 3/6] x86/boot: Introduce efi_get_rsdp_addr() to find RSDP from EFI table Chao Fan
2019-01-10 21:15   ` Borislav Petkov
2019-01-11  1:23     ` Chao Fan
2019-01-11 10:32       ` Borislav Petkov
2019-01-13  9:47         ` Chao Fan [this message]
2019-01-13 11:05           ` Borislav Petkov
2019-01-14  1:26             ` Chao Fan
2019-01-14  9:07               ` Borislav Petkov
2019-01-15  7:21                 ` Chao Fan
2019-01-15  9:55                   ` Borislav Petkov
2019-01-16  3:26                     ` Chao Fan
2019-01-07  3:22 ` [PATCH v15 4/6] x86/boot: Introduce bios_get_rsdp_addr() to search RSDP in memory Chao Fan
2019-01-10 21:27   ` Borislav Petkov
2019-01-11  1:27     ` Chao Fan
2019-01-07  3:22 ` [PATCH v15 5/6] x86/boot: Parse SRAT address from RSDP and store immovable memory Chao Fan
2019-01-16  7:28   ` Kairui Song
2019-01-17  1:42     ` Chao Fan
     [not found]     ` <20190117062451.GA588@localhost.localdomain>
2019-01-17  7:57       ` Chao Fan
2019-01-17  8:22         ` Kairui Song
2019-01-17  9:06           ` Juergen Gross
2019-01-16 11:01   ` Borislav Petkov
2019-01-17  1:16     ` Chao Fan
2019-01-17  3:20     ` Chao Fan
2019-01-17 15:27       ` Borislav Petkov
2019-01-18  1:14         ` Chao Fan
2019-01-21  9:33     ` Chao Fan
2019-01-21  9:42       ` Chao Fan
2019-01-21  9:45         ` Borislav Petkov
2019-01-21  9:51           ` Chao Fan
2019-01-07  3:22 ` [PATCH v15 6/6] x86/boot/KASLR: Limit KASLR to extracting kernel in " Chao Fan
2019-01-16 11:15   ` Borislav Petkov
2019-01-17  1:25     ` 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=20190113094704.GC13263@localhost.localdomain \
    --to=fanc.fnst@cn.fujitsu.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=indou.takao@jp.fujitsu.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.