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 = _params->efi_info;
sig = (char *)>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
