linux-kernel - Re: [PATCH v2] x86/boot: Use EFI setup data if provided

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]

Message-ID: <20190325231000.GA9184@jeru.linux.bs1.fc.nec.co.jp>
Date:   Mon, 25 Mar 2019 23:10:01 +0000
From:   Junichi Nomura <j-nomura@...jp.nec.com>
To:     Borislav Petkov <bp@...en8.de>, Dave Young <dyoung@...hat.com>
CC:     "fanc.fnst@...fujitsu.com" <fanc.fnst@...fujitsu.com>,
        "bhe@...hat.com" <bhe@...hat.com>,
        "kasong@...hat.com" <kasong@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86/boot: Use EFI setup data if provided

On 3/25/19 9:32 PM, Borislav Petkov wrote:
> On Mon, Mar 25, 2019 at 08:23:02PM +0800, Dave Young wrote:
>> Kexec saved the original physical addresses, and pass them to kexeced
>> kernel via x86 setup_data, so  both the early parsing or efi init code
>> need to get those physical values from setup_data.
> 
> So efi_get_rsdp_addr() needs to be refactored in such a way so that at
> least the loop towards the end gets carved out into a separate function
> - __efi_get_rsdp_addr() or so - which gets config_tables, nr_tables and
> size as arguments and finds the RSDP address in the kexec-ed kernel.

Since we still need to read systab for nr_tables and do signature
check to determine if it's 32bit or 64bit for kexec-ed kernel,
everything except the address of config_tables are common between
normal boot and kexec boot.

> So we'd need something like that:
> 
> acpi_physical_address get_rsdp_addr(void)
> {
>         acpi_physical_address pa;
> 
>         pa = get_acpi_rsdp();
> 
>         if (!pa)
>                 pa = boot_params->acpi_rsdp_addr;
> 
>         if (!pa)
>                 pa = efi_get_rsdp_addr();
> 
> 	if (!pa)
> 		pa = kexec_get_rdsp_addr();		<--- new function
> 
>         if (!pa)
>                 pa = bios_get_rsdp_addr();
> 
>         return pa;
> }
> 
> which would get config_tables from setup_data and call
> __efi_get_rsdp_addr() to dig it out in the kexec'ed kernel.
> 
> Junichi, ask if it is still unclear what needs to be done.

efi_get_rsdp_addr() and kexec_get_rsdp_addr() could be implemented
like this (sorry about the pseudo code):

  /* This is also used to check if the kernel is kexec-ed. */
  unsigned long efi_get_setup_data_addr(void) {
    return the address of efi_setup_data if kexec-ed or 0 if not;
  }

  acpi_physical_address __efi_get_rsdp_addr(unsigned long config_tables) {
    // Do mostly same as the current efi_get_rsdp_addr().
    // If config_tables is non-zero, use it instead of systab->tables.
  }

  acpi_physical_address efi_get_rsdp_addr(void) {
    if (efi_get_setup_data_addr())
      return 0;
    return __efi_get_rsdp_addr(0);
  }

  acpi_physical_address kexec_get_rsdp_addr(void) {
    esd = (struct efi_setup_data *) efi_get_setup_data_addr();
    if (esd && esd->tables)
      return __efi_get_rsdp_addr((unsigned long) esd->tables);
    return 0;
  }

I don't think it looks nice.. Does this match what you envisage?

-- 
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.