lkml.org 
[lkml]   [2023]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH RFC v8 52/56] ccp: Add support to decrypt the page
    From


    On 02/03/2023 16:33, Tom Lendacky wrote:
    > On 3/1/23 23:59, Dov Murik wrote:
    >> 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@amd.com> wrote:
    >>>
    >>>> From: Brijesh Singh <brijesh.singh@amd.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@amd.com>
    >>>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
    >>>> [mdr: minor commit fixups]
    >>>> Signed-off-by: Michael Roth <michael.roth@amd.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.
    >
    > This sme_me_mask tells the firmware how to access the host memory
    > (similar to how DMA uses sme_me_mask when supplying addresses to devices
    > under SME). This needs to match the pagetable mapping being used by the
    > host, otherwise the contents will appears as ciphertext to the host if
    > they are not in sync. Since the default pagetable mapping is encrypted,
    > the sme_me_mask bit must be provided on the destination address. So it
    > is not a spec requirement, but an SME implementation requirement.
    >

    Ah, OK, that's clear now. Thanks Tom.

    -Dov

    \
     
     \ /
      Last update: 2023-03-27 00:42    [W:5.898 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site