linux-kernel - Re: [PATCH v15 3/6] x86/boot: Introduce efi_get_rsdp

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:   Sun, 13 Jan 2019 17:47:04 +0800
From:   Chao Fan <fanc.fnst@...fujitsu.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     <linux-kernel@...r.kernel.org>, <x86@...nel.org>,
        <tglx@...utronix.de>, <mingo@...hat.com>, <hpa@...or.com>,
        <keescook@...omium.org>, <bhe@...hat.com>, <msys.mizuma@...il.com>,
        <indou.takao@...fujitsu.com>, <caoj.fnst@...fujitsu.com>
Subject: Re: [PATCH v15 3/6] x86/boot: Introduce efi_get_rsdp_addr() to find
 RSDP from EFI table

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.
>
>