linux-kernel - Re: [tip:x86/boot] x86/boot: Early parse RSDP and save it in boot

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:   Mon, 11 Feb 2019 11:24:26 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Chao Fan <fanc.fnst@...fujitsu.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        "Lendacky, Thomas" <thomas.lendacky@....com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        caoj.fnst@...fujitsu.com, Juergen Gross <jgross@...e.com>,
        Ingo Molnar <mingo@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        linux-tip-commits@...r.kernel.org,
        Matt Fleming <matt@...eblueprint.co.uk>
Subject: Re: [tip:x86/boot] x86/boot: Early parse RSDP and save it in
 boot_params

On Mon, Feb 11, 2019 at 10:17:36AM +0000, Ard Biesheuvel wrote:
> That still does not explain how 'table' can assume a value > 4 GB
> after assigning the contents of a u32 to it.

See efi_get_rsdp_addr() in tip/master and especially that systable address
computation:

#ifdef CONFIG_X86_64
        systab = (efi_system_table_t *)(ei->efi_systab | ((__u64)ei->efi_systab_hi<<32));
#else
        if (ei->efi_systab_hi || ei->efi_memmap_hi) {
                debug_putstr("Error getting RSDP address: EFI system table located above 4GB.\n");
                return 0;
        }
        systab = (efi_system_table_t *)ei->efi_systab;
#endif

	...

	config_tables = (void *)(systab->tables + size * i);

It is hard to debug that early but I managed to singlestep it last night
to this deref:

              } else {
                        efi_config_table_32_t *tmp_table;

                        tmp_table = config_tables;
                        guid = tmp_table->guid;
				^^^^^^^^^^^^^^

                        table = tmp_table->table;

which in asm is:

# arch/x86/boot/compressed/acpi.c:114: 			guid = tmp_table->guid;
#NO_APP
	movq	(%rdi), %rax	# MEM[(struct efi_config_table_32_t *)config_tables_37].guid, guid
	movq	8(%rdi), %rsi	# MEM[(struct efi_config_table_32_t *)config_tables_37].guid, guid
# arch/x86/boot/compressed/acpi.c:115: 			table = tmp_table->table;
	movl	16(%rdi), %r10d	# MEM[(struct efi_config_table_32_t *)config_tables_37].table, table

and %rdi has 0x630646870 so either we got the wrong address or qemu
mapped it above 4G...

It is only an observation for now though...

Thx.

-- 
Regards/Gruss,
    Boris.

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