linux-kernel - Re: [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c0e1cd6a-4065-51ac-a398-aa48245f748f@amd.com>
Date: Sat, 27 Jan 2024 08:43:57 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: Dionna Amalie Glaze <dionnaglaze@...gle.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>,
 Dan Williams <dan.j.williams@...el.com>, Michael Roth
 <michael.roth@....com>, Ashish Kalra <ashish.kalra@....com>
Subject: Re: [PATCH 04/11] x86/sev: Use kernel provided SVSM Calling Areas

On 1/26/24 18:45, Dionna Amalie Glaze wrote:
> On Fri, Jan 26, 2024 at 2:17 PM Tom Lendacky <thomas.lendacky@....com> wrote:
>>
>> The SVSM Calling Area (CA) is used to communicate between Linux and the
>> SVSM. Since the firmware supplied CA for the BSP is likely to be in
>> reserved memory, switch off that CA to a kernel provided CA so that access
>> and use of the CA is available during boot. The CA switch is done using
>> the SVSM core protocol SVSM_CORE_REMAP_CAA call.
> 
> REMAP_CA, not CAA.

Will fix.

> 
>>
>> An SVSM call is executed by filling out the SVSM CA and setting the proper
>> register state as documented by the SVSM protocol. The SVSM is invoked by
>> by requesting the hypervisor to run VMPL0.
>>
>> Once it is safe to allocate/reserve memory, allocate a CA for each CPU.
>> After allocating the new CAs, the BSP will switch from the boot CA to the
>> per-CPU CA. The CA for an AP is identified to the SVSM when creating the
>> VMSA in preparation for booting the AP.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@....com>
>> ---
>>   arch/x86/include/asm/sev-common.h |  13 ++
>>   arch/x86/include/asm/sev.h        |  32 +++++
>>   arch/x86/include/uapi/asm/svm.h   |   1 +
>>   arch/x86/kernel/sev-shared.c      |  94 +++++++++++++-
>>   arch/x86/kernel/sev.c             | 207 +++++++++++++++++++++++++-----
>>   arch/x86/mm/mem_encrypt_amd.c     |   8 +-
>>   6 files changed, 320 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
>> index 68a8cdf6fd6a..71db5ba020b9 100644
>> --- a/arch/x86/include/asm/sev-common.h
>> +++ b/arch/x86/include/asm/sev-common.h

>> +
>> +#define SVSM_CORE_CALL(x)              ((0ULL << 32) | (x))
> 
> Given that we should expect to see other SVSM protocols used in the
> kernel, should we not have
> 
> #define SVSM_PROTOCOL_CALL(protocol, call) (((unsigned long)(protocol)
> << 32) | (call))
> #define SVSM_CORE_PROTOCOL 0
> #define SVSM_ATTESTATION_PROTOCOL 1
> #define SVSM_VTPM_PROTOCOL 2
> 
> And then
> 
> #define SVSM_CORE_CALL(x) SVSM_PROTOCOL_CALL(SVSM_CORE_PROTOCOL, x)
> 
> or be cute and use symbol concatenation like
> 
> #define SVSM_PROTOCOL_ID(id) SVSM_##id##_PROTOCOL
> #define SVSM_CALL(id, call) SVSM_PROTOCOL_CALL(SVSM_PROTOCOL_ID(id), call)
> 
> So you can just do SVSM_CALL(CORE, 0) ?

I thought about doing things along that line. You could do it any number 
of ways, but it really just comes down to preference. I decided with just 
the explicit SVSM_CORE_CALL() form.

Thanks,
Tom

>