Re: [tip:x86/boot] x86/boot: Early parse RSDP and save it in boot_params
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip:x86/boot] x86/boot: Early parse RSDP and save it in boot_params
- From: Borislav Petkov <bp@xxxxxxxxx>
- Date: Mon, 11 Feb 2019 11:24:26 +0100
- Cc: Chao Fan <fanc.fnst@xxxxxxxxxxxxxx>, Guenter Roeck <linux@xxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, "Lendacky, Thomas" <thomas.lendacky@xxxxxxx>, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>, caoj.fnst@xxxxxxxxxxxxxx, Juergen Gross <jgross@xxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Kees Cook <keescook@xxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, linux-tip-commits@xxxxxxxxxxxxxxx, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
- In-reply-to: <CAKv+Gu-Tv=Wxhp9k_f4q+AZ+Wqc+joXrnpbz7aKD=75ZKp2Xcw@mail.gmail.com>
- References: <20190208190248.GA10854@roeck-us.net> <20190208191024.GL674@zn.tnic> <20190208204451.GA14024@roeck-us.net> <20190208215322.GO674@zn.tnic> <20190211002220.GD14948@zn.tnic> <CAKv+Gu-6bxRrn7Ft4cRYzB1Jgca=L_d1u5OU1nUzLe7SBEd=xQ@mail.gmail.com> <20190211095547.GB1651@localhost.localdomain> <CAKv+Gu_r4Vz2BRpRyJ=UsM1r-+CbyP6heggL+qsKKhJ_iTWhFg@mail.gmail.com> <20190211101011.GA5333@localhost.localdomain> <CAKv+Gu-Tv=Wxhp9k_f4q+AZ+Wqc+joXrnpbz7aKD=75ZKp2Xcw@mail.gmail.com>
- User-agent: Mutt/1.10.1 (2018-07-13)
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.
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]