Re: [PATCH 2/3 v9] resource: add the new I/O resource descriptor 'IORES_DESC_RESERVED'
在 2019年03月23日 03:28, Borislav Petkov 写道:
> On Thu, Mar 21, 2019 at 06:33:08PM +0800, Lianbo Jiang wrote:
>> When doing kexec_file_load, the first kernel needs to pass the e820
>
> Please end function names with parentheses.
>
>> reserved ranges to the second kernel.
>
> ... because... ?
>
>> But kernel can not exactly match the e820 reserved ranges
> ^
> the
>
>> when walking through the iomem resources with the descriptor
>> 'IORES_DESC_NONE', because several e820 types( e.g.
>> E820_TYPE_RESERVED_KERN/E820_TYPE_RAM/E820_TYPE_UNUSABLE/E820
>> _TYPE_RESERVED) are converted to the descriptor 'IORES_DESC_NONE'.
>> It may pass these four types to the kdump kernel, that is not desired result.
>
> Rewrite that sentence.
>
>> So, this patch adds a new I/O resource descriptor 'IORES_DESC_RESERVED'
>
> Avoid having "This patch" or "This commit" in the commit message. It is
> tautologically useless.
>
> Also, do
>
> $ git grep 'This patch' Documentation/process
>
> for more details.
>
>> for the iomem resources search interfaces. It is helpful to exactly
>> match the reserved resource ranges when walking through iomem resources.
>>
>> In addition, since the new descriptor 'IORES_DESC_RESERVED' is introduced,
>> these code originally related to the descriptor 'IORES_DESC_NONE' need to
>
> "the code"
>
>> be updated.
>
>> Otherwise, it will be easily confused and also cause some errors.
>
> What errors?
>
>> Because the 'E820_TYPE_RESERVED' type is converted to the new
>> descriptor 'IORES_DESC_RESERVED' instead of 'IORES_DESC_NONE', it has been
>> changed.
>
> That sentence I cannot parse.
Thanks for your comment. I will improve the patch log next post.
>
>> Suggested-by: Borislav Petkov
>> Signed-off-by: Lianbo Jiang
>> ---
>> arch/x86/kernel/e820.c | 2 +-
>> include/linux/ioport.h | 1 +
>> kernel/resource.c | 6 +++---
>> 3 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
>> index 2879e234e193..16fcde196243 100644
>> --- a/arch/x86/kernel/e820.c
>> +++ b/arch/x86/kernel/e820.c
>> @@ -1050,10 +1050,10 @@ static unsigned long __init
>> e820_type_to_iores_desc(struct e820_entry *entry)
>> case E820_TYPE_NVS: return IORES_DESC_ACPI_NV_STORAGE;
>> case E820_TYPE_PMEM:return IORES_DESC_PERSISTENT_MEMORY;
>> case E820_TYPE_PRAM:return
>> IORES_DESC_PERSISTENT_MEMORY_LEGACY;
>> +case E820_TYPE_RESERVED:return IORES_DESC_RESERVED;
>> case E820_TYPE_RESERVED_KERN: /* Fall-through: */
>> case E820_TYPE_RAM: /* Fall-through: */
>> case E820_TYPE_UNUSABLE:/* Fall-through: */
>> -case E820_TYPE_RESERVED:/* Fall-through: */
>> default:return IORES_DESC_NONE;
>> }
>> }
>> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
>> index da0ebaec25f0..6ed59de48bd5 100644
>> --- a/include/linux/ioport.h
>> +++ b/include/linux/ioport.h
>> @@ -133,6 +133,7 @@ enum {
>> IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
>> IORES_DESC_DEVICE_PRIVATE_MEMORY= 6,
>> IORES_DESC_DEVICE_PUBLIC_MEMORY = 7,
>> +IORES_DESC_RESERVED = 8,
>> };
>>
>> /* helpers to define resources */
>
> IORES_DESC_RESERVED is supposed to represent E820_TYPE_RESERVED. And if> that
> is the case, then all three hunks below look wrong to me. If you
> want to pass E820_TYPE_RESERVED ranges, then do that explicitly.
In this function, i printed its values, and only got the value of reserved
type, so i changed the IORES_DESC_NONE to the IORES_DESC_RESERVED.
In addition, after the new descriptor 'IORES_DESC_RESERVED' is introduced,
the IORES_DESC_NONE does not include the IORES_DESC_RESERVED any more, it
could miss to handle the value of the reserved type.
Do you mean i should never touch the three chunks? If i made a mistake, i
will remove this changes next post.
Thanks.
Lianbo
>
>> diff --git a/kernel/resource.c b/kernel/resource.c
>> index e81b17b53fa5..ee7348761858 100644
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
>> @@ -990,7 +990,7 @@ __reserve_region_with_split(struct resource *root,
>> resource_size_t start,
>> res->start = start;
>> res->end = end;
>> res->flags = type | IORESOURCE_BUSY;
>> -res->desc = IORES_DESC_NONE;
>> +res->desc = IORES_DESC_RESERVED;
>>
>> while (1) {
>>
>> @@ -1025,7 +1025,7 @@ __reserve_region_with_split(struct resource *root,
>> resource_size_t start,
>> next_res->start = conflict->end + 1;
>> next_res->end = end;
>> next_res->flags = type | IORESOURCE_BUSY;
>> -next_res->desc = IORES_DESC_NONE;
>> +next_res->desc = IORES_DESC_RESERVED;
>> }
>> } else {
>> res->start = conflict->end
Re: [PATCH] x86/boot: Use EFI setup data if provided
On 3/25/19 3:19 PM, Dave Young wrote:
> On 03/25/19 at 02:01pm, Dave Young wrote:
>> On 03/25/19 at 12:27am, Junichi Nomura wrote:
>>> On Fri, Mar 22, 2019 at 04:23:28PM +0100, Borislav Petkov wrote:
On Fri, Mar 22, 2019 at 11:03:43AM +, Junichi Nomura wrote:
> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> in the early parsing code tries to search RSDP from EFI table but
> whose address is virtual.
>
> Since kexec(1) provides physical address of config_table via boot_params,
> efi_get_rsdp_addr() should look for setup_data in the same way as
> efi_systab_init() in arch/x86/platform/efi/efi.c does.
If the kexec kernel should continue to use efi_systab_init() then you
should make efi_get_rsdp_addr() exit early in the kexec-ed kernel.
>>>
>>> I'm not sure which way kexec devel is going. Added kexec list.
>>> Here is the version that exits early in efi_get_rsdp_addr().
>>>
>>> [PATCH] x86/boot: Don't try to search RSDP from EFI when kexec-booted
>>>
>>> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
>>> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
>>> in the early parsing code tries to search RSDP from EFI table but
>>> whose address is virtual.
>>>
>>> Normally kexec(1) provides physical address of config_table via boot_params
>>> and EFI code uses that during initialization.
>>> For the early boot code, we just exit efi_get_rsdp_addr() early if the
>>> kernel
>>> is booted by kexec.
>>>
>>> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
>>> boot_params")
>>> Signed-off-by: Jun'ichi Nomura
>>> Cc: Chao Fan
>>> Cc: Borislav Petkov
>>>
>>> diff --git a/arch/x86/boot/compressed/acpi.c
>>> b/arch/x86/boot/compressed/acpi.c
>>> index 0ef4ad5..1cefc43 100644
>>> --- a/arch/x86/boot/compressed/acpi.c
>>> +++ b/arch/x86/boot/compressed/acpi.c
>>> @@ -44,6 +44,24 @@ static acpi_physical_address get_acpi_rsdp(void)
>>> return addr;
>>> }
>>>
>>> +static bool is_kexec_booted(void)
>>> +{
>>> + struct setup_data *data;
>>> +
>>> + /*
>>> +* kexec-tools provides EFI setup data so that kexec-ed kernel
>>> +* can find proper tables.
>>> +*/
>>> + data = (struct setup_data *) boot_params->hdr.setup_data;
>>> + while (data) {
>>> + if (data->type == SETUP_EFI)
>>> + return true;
>>> + data = (struct setup_data *) data->next;
>>> + }
>>> +
>>> + return false;
>>> +}
>>> +
>>> /* Search EFI system tables for RSDP. */
>>> static acpi_physical_address efi_get_rsdp_addr(void)
>>> {
>>> @@ -57,6 +75,10 @@ static acpi_physical_address efi_get_rsdp_addr(void)
>>> int size, i;
>>> char *sig;
>>>
>>> + /* If the system is kexec-booted, poking EFI systab may not work. */
>>> + if (is_kexec_booted())
>>> + return 0;
>>> +
>>> ei = &boot_params->efi_info;
>>> sig = (char *)&ei->efi_loader_signature;
>>>
>>>
>>> ___
>>> kexec mailing list
>>> kexec@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/kexec
>>
>> Good catch, this way looks good to me. But the function
>> is_kexec_booted can be compiled when #ifdef CONFIG_EFI
>>
>> Otherwise:
>>
>> Acked-by: Dave Young
>>
>
> Hold on, I replied too quick. One question is does the above patch
> passed your test? It can workaround and skip the wrong phys addr
> issue, but the acpi early parsing still fails because efi_get_rsdp_addr
> return 0?
The patch works for me.
Early parsing fails with the 2nd patch but it boots fine.
EFI initialization is done later without boot_params->acpi_rsdp_addr.
I think that's how v5.0 and earlier kernels work.
> If this is the case you may need go with your old patch.
>
> I think normally people do not see this bug, because kernel will set the
> rsdp in boot_params->acpi_rsdp_addr. Maybe you are testing with
I think it's only done for file-based kexec interface.
> different kernel versions, eg.
>
> old kernel kexec to new kernel.
>
> And the old kernel does not set boot_params->acpi_rsdp_addr
>
> Is this correct?
I'm testing kexec from v5.1-rc1 to v5.1-rc1, i.e. same kernel.
--
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] x86/boot: Use EFI setup data if provided
On Mon, Mar 25, 2019 at 2:20 PM Dave Young wrote:
>
> On 03/25/19 at 02:01pm, Dave Young wrote:
> > On 03/25/19 at 12:27am, Junichi Nomura wrote:
> > > On Fri, Mar 22, 2019 at 04:23:28PM +0100, Borislav Petkov wrote:
> > > > On Fri, Mar 22, 2019 at 11:03:43AM +, Junichi Nomura wrote:
> > > > > Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > > > > boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> > > > > in the early parsing code tries to search RSDP from EFI table but
> > > > > whose address is virtual.
> > > > >
> > > > > Since kexec(1) provides physical address of config_table via
> > > > > boot_params,
> > > > > efi_get_rsdp_addr() should look for setup_data in the same way as
> > > > > efi_systab_init() in arch/x86/platform/efi/efi.c does.
> > > >
> > > > If the kexec kernel should continue to use efi_systab_init() then you
> > > > should make efi_get_rsdp_addr() exit early in the kexec-ed kernel.
> > >
> > > I'm not sure which way kexec devel is going. Added kexec list.
> > > Here is the version that exits early in efi_get_rsdp_addr().
> > >
> > > [PATCH] x86/boot: Don't try to search RSDP from EFI when kexec-booted
> > >
> > > Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > > boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> > > in the early parsing code tries to search RSDP from EFI table but
> > > whose address is virtual.
> > >
> > > Normally kexec(1) provides physical address of config_table via
> > > boot_params
> > > and EFI code uses that during initialization.
> > > For the early boot code, we just exit efi_get_rsdp_addr() early if the
> > > kernel
> > > is booted by kexec.
> > >
> > > Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > > boot_params")
> > > Signed-off-by: Jun'ichi Nomura
> > > Cc: Chao Fan
> > > Cc: Borislav Petkov
> > >
> > > diff --git a/arch/x86/boot/compressed/acpi.c
> > > b/arch/x86/boot/compressed/acpi.c
> > > index 0ef4ad5..1cefc43 100644
> > > --- a/arch/x86/boot/compressed/acpi.c
> > > +++ b/arch/x86/boot/compressed/acpi.c
> > > @@ -44,6 +44,24 @@ static acpi_physical_address get_acpi_rsdp(void)
> > > return addr;
> > > }
> > >
> > > +static bool is_kexec_booted(void)
> > > +{
> > > + struct setup_data *data;
> > > +
> > > + /*
> > > +* kexec-tools provides EFI setup data so that kexec-ed kernel
> > > +* can find proper tables.
> > > +*/
> > > + data = (struct setup_data *) boot_params->hdr.setup_data;
> > > + while (data) {
> > > + if (data->type == SETUP_EFI)
> > > + return true;
> > > + data = (struct setup_data *) data->next;
> > > + }
> > > +
> > > + return false;
> > > +}
> > > +
> > > /* Search EFI system tables for RSDP. */
> > > static acpi_physical_address efi_get_rsdp_addr(void)
> > > {
> > > @@ -57,6 +75,10 @@ static acpi_physical_address efi_get_rsdp_addr(void)
> > > int size, i;
> > > char *sig;
> > >
> > > + /* If the system is kexec-booted, poking EFI systab may not work. */
> > > + if (is_kexec_booted())
> > > + return 0;
> > > +
> > > ei = &boot_params->efi_info;
> > > sig = (char *)&ei->efi_loader_signature;
> > >
> > >
> > > ___
> > > kexec mailing list
> > > kexec@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/kexec
> >
> > Good catch, this way looks good to me. But the function
> > is_kexec_booted can be compiled when #ifdef CONFIG_EFI
> >
> > Otherwise:
> >
> > Acked-by: Dave Young
> >
>
> Hold on, I replied too quick. One question is does the above patch
> passed your test? It can workaround and skip the wrong phys addr
> issue, but the acpi early parsing still fails because efi_get_rsdp_addr
> return 0?
>
> If this is the case you may need go with your old patch.
>
> I think normally people do not see this bug, because kernel will set the
> rsdp in boot_params->acpi_rsdp_addr. Maybe you are testing with
> different kernel versions, eg.
>
> old kernel kexec to new kernel.
>
> And the old kernel does not set boot_params->acpi_rsdp_addr
>
> Is this correct?
>
> Thanks
> Dave
Hi Dave, actually only kexec_file_load will always set the
boot_params->acpi_rsdp_addr. Can't guarantee how user space tools will
prepare the boot_prams if kexec_load is used, so it's should very
likely to happen.
And for the patch, I also think the first patch looks better, if we
just return 0 early in efi_get_rsdp_addr aren't we still failing to
parse the rsdp in early code?
--
Best Regards,
Kairui Song
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3 v9] x86/mm: Change the examination condition to avoid confusion
On Mon, Mar 25, 2019 at 11:11:45AM +0800, lijiang wrote: > I mean it needs to find all the value of the 'IORES_DESC_ACPI_*' type. A function called __ioremap_check_desc_other() needs to find IORES_DESC_ACPI_* types... No, still don't know what you're trying to do. > As above mentioned, it needs to find all the value of the 'IORES_DESC_ACPI_*' > type, so we should explicitly use the 'IORES_DESC_ACPI_*' type as the check > condition instead of the 'IORES_DESC_NONE'. And now the same question I'm asking you each time: WHY does it need to find the ACPI types? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3] kexec: Do not map the kexec area as decrypted when SEV is active
On Mon, Mar 25, 2019 at 09:58:07AM +0800, lijiang wrote: > For the SEV virtual machine, it maps the kexec memroy area as > encrypted, so, no need to invoke this function to change anything. Look at the code: set_memory_decrypted->__set_memory_enc_dec It already *does* invoke this function. > > if (!mem_encrypt_active()) > > > > and heads will spin from all the checking of memory encryption aspects. > > > > So this would need a rework so that there are no multiple confusing > > checks. > > About the three functions, here i copied their comment from the > arch/x86/mm/mem_encrypt.c > Please refer to it. I know that comment - I have asked for it. Now you go and look at the code again with your patch applied. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] x86/boot: Use EFI setup data if provided
On 03/25/19 at 02:01pm, Dave Young wrote:
> On 03/25/19 at 12:27am, Junichi Nomura wrote:
> > On Fri, Mar 22, 2019 at 04:23:28PM +0100, Borislav Petkov wrote:
> > > On Fri, Mar 22, 2019 at 11:03:43AM +, Junichi Nomura wrote:
> > > > Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > > > boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> > > > in the early parsing code tries to search RSDP from EFI table but
> > > > whose address is virtual.
> > > >
> > > > Since kexec(1) provides physical address of config_table via
> > > > boot_params,
> > > > efi_get_rsdp_addr() should look for setup_data in the same way as
> > > > efi_systab_init() in arch/x86/platform/efi/efi.c does.
> > >
> > > If the kexec kernel should continue to use efi_systab_init() then you
> > > should make efi_get_rsdp_addr() exit early in the kexec-ed kernel.
> >
> > I'm not sure which way kexec devel is going. Added kexec list.
> > Here is the version that exits early in efi_get_rsdp_addr().
> >
> > [PATCH] x86/boot: Don't try to search RSDP from EFI when kexec-booted
> >
> > Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> > in the early parsing code tries to search RSDP from EFI table but
> > whose address is virtual.
> >
> > Normally kexec(1) provides physical address of config_table via boot_params
> > and EFI code uses that during initialization.
> > For the early boot code, we just exit efi_get_rsdp_addr() early if the
> > kernel
> > is booted by kexec.
> >
> > Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > boot_params")
> > Signed-off-by: Jun'ichi Nomura
> > Cc: Chao Fan
> > Cc: Borislav Petkov
> >
> > diff --git a/arch/x86/boot/compressed/acpi.c
> > b/arch/x86/boot/compressed/acpi.c
> > index 0ef4ad5..1cefc43 100644
> > --- a/arch/x86/boot/compressed/acpi.c
> > +++ b/arch/x86/boot/compressed/acpi.c
> > @@ -44,6 +44,24 @@ static acpi_physical_address get_acpi_rsdp(void)
> > return addr;
> > }
> >
> > +static bool is_kexec_booted(void)
> > +{
> > + struct setup_data *data;
> > +
> > + /*
> > +* kexec-tools provides EFI setup data so that kexec-ed kernel
> > +* can find proper tables.
> > +*/
> > + data = (struct setup_data *) boot_params->hdr.setup_data;
> > + while (data) {
> > + if (data->type == SETUP_EFI)
> > + return true;
> > + data = (struct setup_data *) data->next;
> > + }
> > +
> > + return false;
> > +}
> > +
> > /* Search EFI system tables for RSDP. */
> > static acpi_physical_address efi_get_rsdp_addr(void)
> > {
> > @@ -57,6 +75,10 @@ static acpi_physical_address efi_get_rsdp_addr(void)
> > int size, i;
> > char *sig;
> >
> > + /* If the system is kexec-booted, poking EFI systab may not work. */
> > + if (is_kexec_booted())
> > + return 0;
> > +
> > ei = &boot_params->efi_info;
> > sig = (char *)&ei->efi_loader_signature;
> >
> >
> > ___
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> Good catch, this way looks good to me. But the function
> is_kexec_booted can be compiled when #ifdef CONFIG_EFI
>
> Otherwise:
>
> Acked-by: Dave Young
>
Hold on, I replied too quick. One question is does the above patch
passed your test? It can workaround and skip the wrong phys addr
issue, but the acpi early parsing still fails because efi_get_rsdp_addr
return 0?
If this is the case you may need go with your old patch.
I think normally people do not see this bug, because kernel will set the
rsdp in boot_params->acpi_rsdp_addr. Maybe you are testing with
different kernel versions, eg.
old kernel kexec to new kernel.
And the old kernel does not set boot_params->acpi_rsdp_addr
Is this correct?
Thanks
Dave
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] x86/boot: Use EFI setup data if provided
On 03/25/19 at 12:27am, Junichi Nomura wrote:
> On Fri, Mar 22, 2019 at 04:23:28PM +0100, Borislav Petkov wrote:
> > On Fri, Mar 22, 2019 at 11:03:43AM +, Junichi Nomura wrote:
> > > Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > > boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> > > in the early parsing code tries to search RSDP from EFI table but
> > > whose address is virtual.
> > >
> > > Since kexec(1) provides physical address of config_table via boot_params,
> > > efi_get_rsdp_addr() should look for setup_data in the same way as
> > > efi_systab_init() in arch/x86/platform/efi/efi.c does.
> >
> > If the kexec kernel should continue to use efi_systab_init() then you
> > should make efi_get_rsdp_addr() exit early in the kexec-ed kernel.
>
> I'm not sure which way kexec devel is going. Added kexec list.
> Here is the version that exits early in efi_get_rsdp_addr().
>
> [PATCH] x86/boot: Don't try to search RSDP from EFI when kexec-booted
>
> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> in the early parsing code tries to search RSDP from EFI table but
> whose address is virtual.
>
> Normally kexec(1) provides physical address of config_table via boot_params
> and EFI code uses that during initialization.
> For the early boot code, we just exit efi_get_rsdp_addr() early if the kernel
> is booted by kexec.
>
> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in boot_params")
> Signed-off-by: Jun'ichi Nomura
> Cc: Chao Fan
> Cc: Borislav Petkov
>
> diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
> index 0ef4ad5..1cefc43 100644
> --- a/arch/x86/boot/compressed/acpi.c
> +++ b/arch/x86/boot/compressed/acpi.c
> @@ -44,6 +44,24 @@ static acpi_physical_address get_acpi_rsdp(void)
> return addr;
> }
>
> +static bool is_kexec_booted(void)
> +{
> + struct setup_data *data;
> +
> + /*
> + * kexec-tools provides EFI setup data so that kexec-ed kernel
> + * can find proper tables.
> + */
> + data = (struct setup_data *) boot_params->hdr.setup_data;
> + while (data) {
> + if (data->type == SETUP_EFI)
> + return true;
> + data = (struct setup_data *) data->next;
> + }
> +
> + return false;
> +}
> +
> /* Search EFI system tables for RSDP. */
> static acpi_physical_address efi_get_rsdp_addr(void)
> {
> @@ -57,6 +75,10 @@ static acpi_physical_address efi_get_rsdp_addr(void)
> int size, i;
> char *sig;
>
> + /* If the system is kexec-booted, poking EFI systab may not work. */
> + if (is_kexec_booted())
> + return 0;
> +
> ei = &boot_params->efi_info;
> sig = (char *)&ei->efi_loader_signature;
>
>
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Good catch, this way looks good to me. But the function
is_kexec_booted can be compiled when #ifdef CONFIG_EFI
Otherwise:
Acked-by: Dave Young
Thanks
Dave
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3 v9] x86/mm: Change the examination condition to avoid confusion
在 2019年03月23日 01:51, Borislav Petkov 写道:
> On Thu, Mar 21, 2019 at 06:33:07PM +0800, Lianbo Jiang wrote:
>> Following the commit <0e4c12b45aa8> ("x86/mm, resource: Use
>> PAGE_KERNEL protection for ioremap of memory pages"),
>
> The proper commit quotation format is done by adding this to your
> .gitconfig:
>
> [core]
> abbrev = 12
> [alias]
> one = show -s --pretty='format:%h (\"%s\")'
>
> and then doing:
>
> $ git one
>
> which will give you
>
> 0e4c12b45aa8 ("x86/mm, resource: Use PAGE_KERNEL protection for ioremap of
> memory pages")
Nice. I added them to my .gitconfig. It works. Thank you very much.
>
>> here it is really checking for the 'IORES_DESC_ACPI_*' values.
>
> Well, it is not really checking that.
I mean it needs to find all the value of the 'IORES_DESC_ACPI_*' type.
>
>> Therefore, it is necessary to change the examination condition
>> to avoid confusion.
>
> What confusion?
As above mentioned, it needs to find all the value of the 'IORES_DESC_ACPI_*'
type, so we should explicitly use the 'IORES_DESC_ACPI_*' type as the check
condition instead of the 'IORES_DESC_NONE'.
Thanks.
Lianbo
>
> The justification for that change sounds really fishy.
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3] kexec: Do not map the kexec area as decrypted when SEV is active
在 2019年03月24日 23:00, Borislav Petkov 写道:
>> Subject: Re: [PATCH 1/3] kexec: Do not map the kexec area as decrypted when
>> SEV is active
>
> The tip tree preferred format for patch subject prefixes is
> 'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
> 'genirq/core:'. Please do not use file names or complete file paths as
> prefix. 'git log path/to/file' should give you a reasonable hint in most
> cases.
Fine, thanks for your advice.
>
> On Fri, Mar 15, 2019 at 06:32:01PM +0800, Lianbo Jiang wrote:
>> Currently, the arch_kexec_post_{alloc,free}_pages unconditionally
>
> Please end function names with parentheses.
Ok, i will improve them next post.
>
>> maps the kexec area as decrypted. This works fine when SME is active.
>> Because in SME, the first kernel is loaded in decrypted area by the
>> BIOS, so the second kernel must be also loaded into the decrypted
>> memory.
>>
>> When SEV is active, the first kernel is loaded into the encrypted
>> area, so the second kernel must be also loaded into the encrypted
>> memory. Lets make sure that arch_kexec_post_{alloc,free}_pages does
>> not clear the memory encryption mask from the kexec area when SEV
>> is active.
>
> Hold on, wait a minute!
>
> Why do we even need this? As usual, you guys never explain what the big
> picture is. So you mention SEV, which sounds to me like you want to be
> able to kexec the SEV *guest*. Yes?
Yes. Just like the physical machines support kdump, the virtual machines also
need kdump. When a virtual machine panic, we also need to dump its memory for
analysis.
>
> First of all, why?
For the SEV virtual machine, the memory is also encrypted. When SEV is enabled,
the first kernel is loaded into the encrypted area. Unlike the SME, the first
kernel is loaded into the decrypted area.
Because of this difference between SME and SEV, we need to properly map the
kexec
memory area in order to correctly access it.
>
> Then, if so...
>
>> Co-developed-by: Brijesh Singh
>> Signed-off-by: Brijesh Singh
>> Signed-off-by: Lianbo Jiang
>> ---
>> arch/x86/kernel/machine_kexec_64.c | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index ceba408ea982..bcebf4993da4 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -566,7 +566,10 @@ int arch_kexec_post_alloc_pages(void *vaddr, unsigned
>> int pages, gfp_t gfp)
>> * not encrypted because when we boot to the new kernel the
>> * pages won't be accessed encrypted (initially).
>> */
>> -return set_memory_decrypted((unsigned long)vaddr, pages);
>> +if (sme_active())
>> +return set_memory_decrypted((unsigned long)vaddr, pages);
>
> ... then this looks yucky. Because, you're adding an sme_active() check here
> but then __set_memory_enc_dec() checks
For the SEV virtual machine, it maps the kexec memroy area as encrypted, so, no
need to invoke
this function to change anything.
>
> if (!mem_encrypt_active())
>
> and heads will spin from all the checking of memory encryption aspects.
>
> So this would need a rework so that there are no multiple confusing
> checks.
About the three functions, here i copied their comment from the
arch/x86/mm/mem_encrypt.c
Please refer to it.
/*
* SME and SEV are very similar but they are not the same, so there are
* times that the kernel will need to distinguish between SME and SEV. The
* sme_active() and sev_active() functions are used for this. When a
* distinction isn't needed, the mem_encrypt_active() function can be used.
*
Thanks.
Lianbo
>
> Thx.
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] x86/boot: Use EFI setup data if provided
On Fri, Mar 22, 2019 at 04:23:28PM +0100, Borislav Petkov wrote:
> On Fri, Mar 22, 2019 at 11:03:43AM +, Junichi Nomura wrote:
> > Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
> > boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
> > in the early parsing code tries to search RSDP from EFI table but
> > whose address is virtual.
> >
> > Since kexec(1) provides physical address of config_table via boot_params,
> > efi_get_rsdp_addr() should look for setup_data in the same way as
> > efi_systab_init() in arch/x86/platform/efi/efi.c does.
>
> If the kexec kernel should continue to use efi_systab_init() then you
> should make efi_get_rsdp_addr() exit early in the kexec-ed kernel.
I'm not sure which way kexec devel is going. Added kexec list.
Here is the version that exits early in efi_get_rsdp_addr().
[PATCH] x86/boot: Don't try to search RSDP from EFI when kexec-booted
Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in
boot_params") broke kexec boot on EFI systems. efi_get_rsdp_addr()
in the early parsing code tries to search RSDP from EFI table but
whose address is virtual.
Normally kexec(1) provides physical address of config_table via boot_params
and EFI code uses that during initialization.
For the early boot code, we just exit efi_get_rsdp_addr() early if the kernel
is booted by kexec.
Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in boot_params")
Signed-off-by: Jun'ichi Nomura
Cc: Chao Fan
Cc: Borislav Petkov
diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
index 0ef4ad5..1cefc43 100644
--- a/arch/x86/boot/compressed/acpi.c
+++ b/arch/x86/boot/compressed/acpi.c
@@ -44,6 +44,24 @@ static acpi_physical_address get_acpi_rsdp(void)
return addr;
}
+static bool is_kexec_booted(void)
+{
+ struct setup_data *data;
+
+ /*
+* kexec-tools provides EFI setup data so that kexec-ed kernel
+* can find proper tables.
+*/
+ data = (struct setup_data *) boot_params->hdr.setup_data;
+ while (data) {
+ if (data->type == SETUP_EFI)
+ return true;
+ data = (struct setup_data *) data->next;
+ }
+
+ return false;
+}
+
/* Search EFI system tables for RSDP. */
static acpi_physical_address efi_get_rsdp_addr(void)
{
@@ -57,6 +75,10 @@ static acpi_physical_address efi_get_rsdp_addr(void)
int size, i;
char *sig;
+ /* If the system is kexec-booted, poking EFI systab may not work. */
+ if (is_kexec_booted())
+ return 0;
+
ei = &boot_params->efi_info;
sig = (char *)&ei->efi_loader_signature;
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3] kexec: Do not map the kexec area as decrypted when SEV is active
> Subject: Re: [PATCH 1/3] kexec: Do not map the kexec area as decrypted when
> SEV is active
The tip tree preferred format for patch subject prefixes is
'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
'genirq/core:'. Please do not use file names or complete file paths as
prefix. 'git log path/to/file' should give you a reasonable hint in most
cases.
On Fri, Mar 15, 2019 at 06:32:01PM +0800, Lianbo Jiang wrote:
> Currently, the arch_kexec_post_{alloc,free}_pages unconditionally
Please end function names with parentheses.
> maps the kexec area as decrypted. This works fine when SME is active.
> Because in SME, the first kernel is loaded in decrypted area by the
> BIOS, so the second kernel must be also loaded into the decrypted
> memory.
>
> When SEV is active, the first kernel is loaded into the encrypted
> area, so the second kernel must be also loaded into the encrypted
> memory. Lets make sure that arch_kexec_post_{alloc,free}_pages does
> not clear the memory encryption mask from the kexec area when SEV
> is active.
Hold on, wait a minute!
Why do we even need this? As usual, you guys never explain what the big
picture is. So you mention SEV, which sounds to me like you want to be
able to kexec the SEV *guest*. Yes?
First of all, why?
Then, if so...
> Co-developed-by: Brijesh Singh
> Signed-off-by: Brijesh Singh
> Signed-off-by: Lianbo Jiang
> ---
> arch/x86/kernel/machine_kexec_64.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/machine_kexec_64.c
> b/arch/x86/kernel/machine_kexec_64.c
> index ceba408ea982..bcebf4993da4 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -566,7 +566,10 @@ int arch_kexec_post_alloc_pages(void *vaddr, unsigned
> int pages, gfp_t gfp)
>* not encrypted because when we boot to the new kernel the
>* pages won't be accessed encrypted (initially).
>*/
> - return set_memory_decrypted((unsigned long)vaddr, pages);
> + if (sme_active())
> + return set_memory_decrypted((unsigned long)vaddr, pages);
... then this looks yucky. Because, you're adding an sme_active() check here
but then __set_memory_enc_dec() checks
if (!mem_encrypt_active())
and heads will spin from all the checking of memory encryption aspects.
So this would need a rework so that there are no multiple confusing
checks.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
