linux-kernel - Re: [PATCH v1 18/26] crypto: ccp: Handle legacy SEV commands when SNP is enabled

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]

Date: Fri, 19 Jan 2024 11:36:44 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: Borislav Petkov <bp@...en8.de>, Michael Roth <michael.roth@....com>
Cc: x86@...nel.org, kvm@...r.kernel.org, linux-coco@...ts.linux.dev,
 linux-mm@...ck.org, linux-crypto@...r.kernel.org,
 linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
 jroedel@...e.de, hpa@...or.com, ardb@...nel.org, pbonzini@...hat.com,
 seanjc@...gle.com, vkuznets@...hat.com, jmattson@...gle.com,
 luto@...nel.org, dave.hansen@...ux.intel.com, slp@...hat.com,
 pgonda@...gle.com, peterz@...radead.org,
 srinivas.pandruvada@...ux.intel.com, rientjes@...gle.com, tobin@....com,
 vbabka@...e.cz, kirill@...temov.name, ak@...ux.intel.com,
 tony.luck@...el.com, sathyanarayanan.kuppuswamy@...ux.intel.com,
 alpergun@...gle.com, jarkko@...nel.org, ashish.kalra@....com,
 nikunj.dadhania@....com, pankaj.gupta@....com, liam.merwick@...cle.com
Subject: Re: [PATCH v1 18/26] crypto: ccp: Handle legacy SEV commands when SNP
 is enabled

On 1/19/24 11:18, Borislav Petkov wrote:
> On Sat, Dec 30, 2023 at 10:19:46AM -0600, Michael Roth wrote:
>> From: Brijesh Singh <brijesh.singh@....com>
>>
>> The behavior of legacy SEV commands is altered when the firmware is
>> initialized for SNP support. In that case, all command buffer memory
>> that may get written to by legacy SEV commands must be marked as
>> firmware-owned in the RMP table prior to issuing the command.
>>
>> Additionally, when a command buffer contains a system physical address
>> that points to additional buffers that firmware may write to, special
>> handling is needed depending on whether:
>>
>>    1) the system physical address points to guest memory
>>    2) the system physical address points to host memory
>>
>> To handle case #1, the pages of these buffers are changed to
>> firmware-owned in the RMP table before issuing the command, and restored
>> to after the command completes.
>>
>> For case #2, a bounce buffer is used instead of the original address.
>>
>> Signed-off-by: Brijesh Singh <brijesh.singh@....com>
>> Co-developed-by: Michael Roth <michael.roth@....com>
>> Signed-off-by: Michael Roth <michael.roth@....com>
>> Signed-off-by: Ashish Kalra <ashish.kalra@....com>
>> ---
>>   drivers/crypto/ccp/sev-dev.c | 421 ++++++++++++++++++++++++++++++++++-
>>   drivers/crypto/ccp/sev-dev.h |   3 +
>>   2 files changed, 414 insertions(+), 10 deletions(-)
> 
> Definitely better, thanks.
> 
> Some cleanups ontop:
> 
> ---
> 

> @@ -904,7 +904,7 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret)
>   		ret = snp_prep_cmd_buf(cmd, cmd_buf, desc_list);
>   		if (ret) {
>   			dev_err(sev->dev,
> -				"SEV: failed to prepare buffer for legacy command %#x. Error: %d\n",
> +				"SEV: failed to prepare buffer for legacy command 0x%#x. Error: %d\n",

Using %#x will produce the 0x in the output (except if the value is zero 
for some reason). So I would say make that 0x%x.

Thanks,
Tom

>   				cmd, ret);
>   			return ret;
>   		}
> 
>