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: <e63ba525-644d-1a8c-afe7-2ced4a8fbb93@linux.ibm.com>
Date:   Thu, 2 Mar 2023 07:59:24 +0200
From:   Dov Murik <dovmurik@...ux.ibm.com>
To:     Zhi Wang <zhi.wang.linux@...il.com>,
        Michael Roth <michael.roth@....com>
Cc:     kvm@...r.kernel.org, linux-coco@...ts.linux.dev,
        linux-mm@...ck.org, linux-crypto@...r.kernel.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
        jroedel@...e.de, thomas.lendacky@....com, 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, bp@...en8.de, vbabka@...e.cz,
        kirill@...temov.name, ak@...ux.intel.com, tony.luck@...el.com,
        marcorr@...gle.com, sathyanarayanan.kuppuswamy@...ux.intel.com,
        alpergun@...gle.com, dgilbert@...hat.com, jarkko@...nel.org,
        ashish.kalra@....com, nikunj.dadhania@....com,
        Brijesh Singh <brijesh.singh@....com>,
        Dov Murik <dovmurik@...ux.ibm.com>
Subject: Re: [PATCH RFC v8 52/56] ccp: Add support to decrypt the page

Hi Mike, Zhi,

On 01/03/2023 23:20, Zhi Wang wrote:
> On Mon, 20 Feb 2023 12:38:43 -0600
> Michael Roth <michael.roth@....com> wrote:
> 
>> From: Brijesh Singh <brijesh.singh@....com>
>>
>> Add support to decrypt guest encrypted memory. These API interfaces can
>> be used for example to dump VMCBs on SNP guest exit.
>>
> 
> What kinds of check will be applied from firmware when VMM decrypts this
> page? I suppose there has to be kinda mechanism to prevent VMM to decrypt
> any page in the guest. It would be nice to have some introduction about
> it in the comments.
> 

The SNP ABI spec says (section 8.27.2 SNP_DBG_DECRYPT):

  The firmware checks that the guest's policy allows debugging. If not,
  the firmware returns POLICY_FAILURE.

and in the Guest Policy (section 4.3):

  Bit 19 - DEBUG
  0: Debugging is disallowed.
  1: Debugging is allowed.

In the kernel, that firmware error code is defined as
SEV_RET_POLICY_FAILURE.


>> Signed-off-by: Brijesh Singh <brijesh.singh@....com>
>> Signed-off-by: Ashish Kalra <ashish.kalra@....com>
>> [mdr: minor commit fixups]
>> Signed-off-by: Michael Roth <michael.roth@....com>
>> ---
>>  drivers/crypto/ccp/sev-dev.c | 32 ++++++++++++++++++++++++++++++++
>>  include/linux/psp-sev.h      | 22 ++++++++++++++++++++--
>>  2 files changed, 52 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>> index e65563bc8298..bf5167b2acfc 100644
>> --- a/drivers/crypto/ccp/sev-dev.c
>> +++ b/drivers/crypto/ccp/sev-dev.c
>> @@ -2017,6 +2017,38 @@ int sev_guest_df_flush(int *error)
>>  }
>>  EXPORT_SYMBOL_GPL(sev_guest_df_flush);
>>  
>> +int snp_guest_dbg_decrypt_page(u64 gctx_pfn, u64 src_pfn, u64 dst_pfn, int *error)
>> +{
>> +	struct sev_data_snp_dbg data = {0};
>> +	struct sev_device *sev;
>> +	int ret;
>> +
>> +	if (!psp_master || !psp_master->sev_data)
>> +		return -ENODEV;
>> +
>> +	sev = psp_master->sev_data;
>> +
>> +	if (!sev->snp_initialized)
>> +		return -EINVAL;
>> +
>> +	data.gctx_paddr = sme_me_mask | (gctx_pfn << PAGE_SHIFT);
>> +	data.src_addr = sme_me_mask | (src_pfn << PAGE_SHIFT);
>> +	data.dst_addr = sme_me_mask | (dst_pfn << PAGE_SHIFT);

I guess this works, but I wonder why we need to turn on sme_me_mask on
teh dst_addr.  I thought that the firmware decrypts the guest page
(src_addr) to a plaintext page.  Couldn't find this requirement in the
SNP spec.


>> +
>> +	/* The destination page must be in the firmware state. */
>> +	if (rmp_mark_pages_firmware(data.dst_addr, 1, false))
>> +		return -EIO;
>> +
>> +	ret = sev_do_cmd(SEV_CMD_SNP_DBG_DECRYPT, &data, error);
>> +
>> +	/* Restore the page state */
>> +	if (snp_reclaim_pages(data.dst_addr, 1, false))
>> +		ret = -EIO;
>> +
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(snp_guest_dbg_decrypt_page);
>> +
>>  int snp_guest_ext_guest_request(struct sev_data_snp_guest_request *data,
>>  				unsigned long vaddr, unsigned long *npages, unsigned long *fw_err)
>>  {
>> diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
>> index 81bafc049eca..92116e2b74fd 100644
>> --- a/include/linux/psp-sev.h
>> +++ b/include/linux/psp-sev.h
>> @@ -710,7 +710,6 @@ struct sev_data_snp_dbg {
>>  	u64 gctx_paddr;				/* In */
>>  	u64 src_addr;				/* In */
>>  	u64 dst_addr;				/* In */
>> -	u32 len;				/* In */
>>  } __packed;

The comment above this ^^^ struct still lists the 'len' field, and also
calls the first field 'handle' instead of 'gctx_paddr'.

Also - why is this change happening in this patch? Why was the incorrect
'len' field added in the first place in "[PATCH RFC v8 20/56]
crypto:ccp: Define the SEV-SNP commands" ? (the comment fixes should
probably go there too).



>>  
>>  /**
>> @@ -913,13 +912,27 @@ int sev_guest_decommission(struct sev_data_decommission *data, int *error);
>>   * @error: SEV command return code
>>   *
>>   * Returns:
>> + * 0 if the sev successfully processed the command
>> + * -%ENODEV    if the sev device is not available
>> + * -%ENOTSUPP  if the sev does not support SEV
>> + * -%ETIMEDOUT if the sev command timed out
>> + * -%EIO       if the sev returned a non-zero return code
>> + */

I think that if the word 'sev' would be 'SEV' in this comment, the diff
will be a bit less misleading (basically this patch should not introduce
changes to sev_do_cmd).

-Dov

>> +int sev_do_cmd(int cmd, void *data, int *psp_ret);
>> +
>> +/**
>> + * snp_guest_dbg_decrypt_page - perform SEV SNP_DBG_DECRYPT command
>> + *
>> + * @sev_ret: sev command return code
>> + *
>> + * Returns:
>>   * 0 if the SEV successfully processed the command
>>   * -%ENODEV    if the SEV device is not available
>>   * -%ENOTSUPP  if the SEV does not support SEV
>>   * -%ETIMEDOUT if the SEV command timed out
>>   * -%EIO       if the SEV returned a non-zero return code
>>   */
>> -int sev_do_cmd(int cmd, void *data, int *psp_ret);
>> +int snp_guest_dbg_decrypt_page(u64 gctx_pfn, u64 src_pfn, u64 dst_pfn, int *error);
>>  
>>  void *psp_copy_user_blob(u64 uaddr, u32 len);
>>  void *snp_alloc_firmware_page(gfp_t mask);
>> @@ -987,6 +1000,11 @@ static inline void *psp_copy_user_blob(u64 __user uaddr, u32 len) { return ERR_P
>>  
>>  void snp_mark_pages_offline(unsigned long pfn, unsigned int npages) {}
>>  
>> +static inline int snp_guest_dbg_decrypt_page(u64 gctx_pfn, u64 src_pfn, u64 dst_pfn, int *error)
>> +{
>> +	return -ENODEV;
>> +}
>> +
>>  static inline void *snp_alloc_firmware_page(gfp_t mask)
>>  {
>>  	return NULL;
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ