linux-kernel - Re: [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel

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:   Thu, 11 Apr 2019 09:14:36 +0000
From:   Junichi Nomura <j-nomura@...jp.nec.com>
To:     Baoquan He <bhe@...hat.com>
CC:     Borislav Petkov <bp@...en8.de>, Dave Young <dyoung@...hat.com>,
        Chao Fan <fanc.fnst@...fujitsu.com>,
        Kairui Song <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 v4] x86/boot: Use efi_setup_data for searching RSDP on
 kexec-ed kernel

On 4/11/19 5:42 PM, Baoquan He wrote:
> On 04/11/19 at 08:16am, Junichi Nomura wrote:
>> kexec_get_rsdp_addr() might fail on kexec-booted kernel, e.g. if the
>> setup_data was invalid. In such a case, falling back to efi_get_rsdp_addr()
>> will hit the problem of accessing invalid table pointer again.
> 
> Seems you are trying to address Dave Young's comment in 
> http://lkml.kernel.org/r/20190404073233.GC5708@dhcp-128-65.nay.redhat.com

Right. His "In case kexec_get_rsdp_addr failed.." comment.

> We may need discuss and make clear if those are doable. E.g the first
> comment, if not hang by below line of code, returning 0 for what? Can
> kexec still be saved, or just reset to firmware?
> 
> 	error("EFI system table not found in kexec boot_params.")

If we return 0 and also don't hang in the rest of get_rsdp_addr(),
it just work as the same way as v5.0 and earlier kernel do.

Failure cases in kexec_get_rsdp_addr() are followings:
1. efi_setup_data is invalid
2. loader signature is invalid
3. EFI systab is not found in boot_params
4. RSDP is not found by parsing tables pointed to by efi_setup_data

I think all of them are critical for EFI boot, so one option could be
we never return failure in kexec_get_rsdp_addr() and just hang.
But hanging in this very early stage of boot may make the problem
harder to investigate once happens. Even earlyprintk is not working yet.
So the other option is returning 0 to defer the crash for later stage.

> It may need be clarified firstly, then go further to rearrange patch.
> That can ease the work, I guess.
> 
> Personal opinion.

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