From: Junichi Nomura <j-nomura@ce.jp.nec.com> To: Borislav Petkov <bp@alien8.de> Cc: Dave Young <dyoung@redhat.com>, Chao Fan <fanc.fnst@cn.fujitsu.com>, Baoquan He <bhe@redhat.com>, Kairui Song <kasong@redhat.com>, "x86@kernel.org" <x86@kernel.org>, "kexec@lists.infradead.org" <kexec@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Date: Wed, 10 Apr 2019 23:34:51 +0000 [thread overview] Message-ID: <7cbc096d-0548-18b1-a335-8ba114f234a7@ce.jp.nec.com> (raw) In-Reply-To: <20190410171431.GE26580@zn.tnic> On 4/11/19 2:14 AM, Borislav Petkov wrote: > On Mon, Apr 08, 2019 at 11:10:17PM +0000, Junichi Nomura wrote: >> -#ifdef CONFIG_EFI >> - unsigned long systab, systab_tables, config_tables; >> - unsigned int nr_tables; >> +static void efi_read_boot_params(void) >> +{ >> + struct efi_setup_data *esd; >> struct efi_info *ei; >> - bool efi_64; >> - int size, i; >> char *sig; >> >> + kexec_efi_setup_data = efi_get_kexec_setup_data_addr(); > > Why is that written here and tested in another function?!? Both efi_get_rsdp_addr() and kexec_get_rsdp_addr() need to check the result of efi_get_kexec_setup_data_addr(); the former to check whether to exit early, the latter to use the address of the tables. I thought it's better to store the result instead of calling twice. >> + >> ei = &boot_params->efi_info; >> sig = (char *)&ei->efi_loader_signature; >> >> if (!strncmp(sig, EFI64_LOADER_SIGNATURE, 4)) { >> efi_64 = true; >> + efi_booted = true; > > What is that ugliness for? Have you heard of functions returning values? Same as above. I didn't want to do signature check twice, in efi_get_rsdp_addr() and kexec_get_rsdp_addr(). Also, the signature check has 2 return values, whether it was 32bit or 64bit, and whether the signature was valid or not. I could return one of them via pointer passed parameter but I thought it's a little bit ugly. Or I could encode them as something like EFI_SIGNATURE_64, EFI_SIGNATURE_32, and EFI_SIGNATURE_INVALID. But I'm not sure it's good to introduce such a thing just for here. >> +static acpi_physical_address efi_get_rsdp_addr(void) >> +{ >> +#ifdef CONFIG_EFI >> + unsigned long config_tables; >> + unsigned int nr_tables; >> + >> + efi_read_boot_params(); > > Why do you read boot params here? > > No, no, no. > > First you do > > efi_get_rsdp_addr() > > if you cannot get an address, you But efi_get_rsdp_addr() needs to check whether the kernel was kexec booted to avoid accessing invalid EFI table address. efi_get_kexec_setup_data_addr() is the only method I know to check if it was kexec-booted. > - parse boot params > - then parse EFI tables from the address the kexeced kernel received > > No intermixing of code paths and assigning variables in one function and > using them in another. Yeah, I don't like that. But if we are to handle 32bit EFI case, efi_get_rsdp_addr() and kexec_get_rsdp_addr() become full of duplication. > You were on the right track with v3... -- Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
WARNING: multiple messages have this Message-ID (diff)
From: Junichi Nomura <j-nomura@ce.jp.nec.com> To: Borislav Petkov <bp@alien8.de> Cc: Chao Fan <fanc.fnst@cn.fujitsu.com>, Kairui Song <kasong@redhat.com>, Baoquan He <bhe@redhat.com>, "x86@kernel.org" <x86@kernel.org>, "kexec@lists.infradead.org" <kexec@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Dave Young <dyoung@redhat.com> Subject: Re: [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Date: Wed, 10 Apr 2019 23:34:51 +0000 [thread overview] Message-ID: <7cbc096d-0548-18b1-a335-8ba114f234a7@ce.jp.nec.com> (raw) In-Reply-To: <20190410171431.GE26580@zn.tnic> On 4/11/19 2:14 AM, Borislav Petkov wrote: > On Mon, Apr 08, 2019 at 11:10:17PM +0000, Junichi Nomura wrote: >> -#ifdef CONFIG_EFI >> - unsigned long systab, systab_tables, config_tables; >> - unsigned int nr_tables; >> +static void efi_read_boot_params(void) >> +{ >> + struct efi_setup_data *esd; >> struct efi_info *ei; >> - bool efi_64; >> - int size, i; >> char *sig; >> >> + kexec_efi_setup_data = efi_get_kexec_setup_data_addr(); > > Why is that written here and tested in another function?!? Both efi_get_rsdp_addr() and kexec_get_rsdp_addr() need to check the result of efi_get_kexec_setup_data_addr(); the former to check whether to exit early, the latter to use the address of the tables. I thought it's better to store the result instead of calling twice. >> + >> ei = &boot_params->efi_info; >> sig = (char *)&ei->efi_loader_signature; >> >> if (!strncmp(sig, EFI64_LOADER_SIGNATURE, 4)) { >> efi_64 = true; >> + efi_booted = true; > > What is that ugliness for? Have you heard of functions returning values? Same as above. I didn't want to do signature check twice, in efi_get_rsdp_addr() and kexec_get_rsdp_addr(). Also, the signature check has 2 return values, whether it was 32bit or 64bit, and whether the signature was valid or not. I could return one of them via pointer passed parameter but I thought it's a little bit ugly. Or I could encode them as something like EFI_SIGNATURE_64, EFI_SIGNATURE_32, and EFI_SIGNATURE_INVALID. But I'm not sure it's good to introduce such a thing just for here. >> +static acpi_physical_address efi_get_rsdp_addr(void) >> +{ >> +#ifdef CONFIG_EFI >> + unsigned long config_tables; >> + unsigned int nr_tables; >> + >> + efi_read_boot_params(); > > Why do you read boot params here? > > No, no, no. > > First you do > > efi_get_rsdp_addr() > > if you cannot get an address, you But efi_get_rsdp_addr() needs to check whether the kernel was kexec booted to avoid accessing invalid EFI table address. efi_get_kexec_setup_data_addr() is the only method I know to check if it was kexec-booted. > - parse boot params > - then parse EFI tables from the address the kexeced kernel received > > No intermixing of code paths and assigning variables in one function and > using them in another. Yeah, I don't like that. But if we are to handle 32bit EFI case, efi_get_rsdp_addr() and kexec_get_rsdp_addr() become full of duplication. > You were on the right track with v3... -- Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2019-04-10 23:37 UTC|newest] Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-08 23:10 [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Junichi Nomura 2019-04-08 23:10 ` Junichi Nomura 2019-04-10 17:14 ` Borislav Petkov 2019-04-10 17:14 ` Borislav Petkov 2019-04-10 23:34 ` Junichi Nomura [this message] 2019-04-10 23:34 ` Junichi Nomura 2019-04-11 8:09 ` Borislav Petkov 2019-04-11 8:09 ` Borislav Petkov 2019-04-11 8:16 ` Junichi Nomura 2019-04-11 8:16 ` Junichi Nomura 2019-04-11 8:37 ` Borislav Petkov 2019-04-11 8:37 ` Borislav Petkov 2019-04-11 9:13 ` Junichi Nomura 2019-04-11 9:13 ` Junichi Nomura 2019-04-11 9:21 ` Boris Petkov 2019-04-11 9:21 ` Boris Petkov 2019-04-11 9:32 ` Junichi Nomura 2019-04-11 9:32 ` Junichi Nomura 2019-04-11 9:40 ` Boris Petkov 2019-04-11 9:40 ` Boris Petkov 2019-04-11 12:58 ` Borislav Petkov 2019-04-11 12:58 ` Borislav Petkov 2019-04-12 2:54 ` Junichi Nomura 2019-04-12 2:54 ` Junichi Nomura 2019-04-12 8:49 ` Borislav Petkov 2019-04-12 8:49 ` Borislav Petkov 2019-04-12 13:35 ` Borislav Petkov 2019-04-12 13:35 ` Borislav Petkov 2019-04-15 7:01 ` Junichi Nomura 2019-04-15 7:01 ` Junichi Nomura 2019-04-15 9:07 ` Borislav Petkov 2019-04-15 9:07 ` Borislav Petkov 2019-04-15 10:25 ` Borislav Petkov 2019-04-15 10:25 ` Borislav Petkov 2019-04-15 23:00 ` Junichi Nomura 2019-04-15 23:00 ` Junichi Nomura 2019-04-15 23:14 ` Junichi Nomura 2019-04-15 23:14 ` Junichi Nomura 2019-04-16 9:45 ` Borislav Petkov 2019-04-16 9:45 ` Borislav Petkov 2019-04-16 23:09 ` kexec crash on OVMF i386 + x86_64 kernel (Re: [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel) Junichi Nomura 2019-04-16 23:09 ` Junichi Nomura 2019-04-17 5:14 ` Dave Young 2019-04-17 5:14 ` Dave Young 2019-04-17 17:57 ` Prakhya, Sai Praneeth 2019-04-17 17:57 ` Prakhya, Sai Praneeth 2019-04-16 9:40 ` [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Borislav Petkov 2019-04-16 9:40 ` Borislav Petkov 2019-04-16 9:52 ` [PATCH] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernels Borislav Petkov 2019-04-16 9:52 ` Borislav Petkov 2019-04-16 10:02 ` Ingo Molnar 2019-04-16 10:02 ` Ingo Molnar 2019-04-16 10:31 ` Borislav Petkov 2019-04-16 10:31 ` Borislav Petkov 2019-04-16 11:41 ` Dave Young 2019-04-16 11:41 ` Dave Young 2019-04-16 13:22 ` Borislav Petkov 2019-04-16 13:22 ` Borislav Petkov 2019-04-17 1:38 ` Dave Young 2019-04-17 1:38 ` Dave Young 2019-04-17 4:57 ` Dave Young 2019-04-17 4:57 ` Dave Young 2019-04-17 6:00 ` Kairui Song 2019-04-17 6:00 ` Kairui Song 2019-04-17 7:08 ` Dave Young 2019-04-17 7:08 ` Dave Young 2019-04-17 8:22 ` Borislav Petkov 2019-04-17 8:22 ` Borislav Petkov 2019-04-18 1:24 ` Dave Young 2019-04-18 1:24 ` Dave Young 2019-04-19 8:34 ` [RFC PATCH] kexec, x86/boot: map systab region in identity mapping before accessing it Kairui Song 2019-04-19 8:34 ` Kairui Song 2019-04-19 8:58 ` Baoquan He 2019-04-19 8:58 ` Baoquan He 2019-04-19 9:39 ` Kairui Song 2019-04-19 9:39 ` Kairui Song 2019-04-16 22:44 ` [PATCH v4] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernel Junichi Nomura 2019-04-16 22:44 ` Junichi Nomura 2019-04-17 7:02 ` Dave Young 2019-04-17 7:02 ` Dave Young 2019-04-17 8:54 ` Borislav Petkov 2019-04-17 8:54 ` Borislav Petkov 2019-04-17 9:02 ` Borislav Petkov 2019-04-17 9:02 ` Borislav Petkov 2019-04-17 10:31 ` Chao Fan 2019-04-17 10:31 ` Chao Fan 2019-04-11 8:42 ` Baoquan He 2019-04-11 8:42 ` Baoquan He 2019-04-11 9:14 ` Junichi Nomura 2019-04-11 9:14 ` Junichi Nomura 2019-04-12 0:23 ` Baoquan He 2019-04-12 0:23 ` Baoquan He 2019-04-15 7:46 ` Dave Young 2019-04-15 7:46 ` Dave Young 2019-06-06 19:22 ` [tip:x86/boot] x86/boot: Use efi_setup_data for searching RSDP on kexec-ed kernels tip-bot for Junichi Nomura
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=7cbc096d-0548-18b1-a335-8ba114f234a7@ce.jp.nec.com \ --to=j-nomura@ce.jp.nec.com \ --cc=bhe@redhat.com \ --cc=bp@alien8.de \ --cc=dyoung@redhat.com \ --cc=fanc.fnst@cn.fujitsu.com \ --cc=kasong@redhat.com \ --cc=kexec@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.