Re: [PATCH 1/3] kexec: Do not map the kexec area as decrypted when SEV is active

[lijiang]

å 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 <brijesh.singh@xxxxxxx>
>> Signed-off-by: Brijesh Singh <brijesh.singh@xxxxxxx>
>> Signed-off-by: Lianbo Jiang <lijiang@xxxxxxxxxx>
>> ---
>>  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.
>