All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.