From nobody Sun Apr 12 00:53:18 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45DD8C3F6B0 for ; Tue, 2 Aug 2022 18:56:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230214AbiHBS4G (ORCPT ); Tue, 2 Aug 2022 14:56:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230283AbiHBSzv (ORCPT ); Tue, 2 Aug 2022 14:55:51 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1CF29140F3 for ; Tue, 2 Aug 2022 11:55:50 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id o12-20020a170902d4cc00b0016e81c62cc8so6590078plg.13 for ; Tue, 02 Aug 2022 11:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:from:to:cc; bh=30XQYa5vrUU1iEUJfeVFtkHZOATBPFqy9Zstl/P+5z8=; b=U/mM+hN/C9aAjBSxsdYTboDvUHBaLxpmZHMEt1gXXrEYG5YnjVUHfwWO9nmAq85hJz UTR5zjqMgwVwaTR19xC5TJQgFnhfameFuoB+lfYBuuUy4D1niJ6wZ62eikVApZlFeFMR aMkbolcOb6t6yrchlJNNedj2XApSOt6SyAvuW59QBWSHdtP+wZxcMH4hDFPeDtnsQqDp 26zMYgyhgUITcYf/alnF6RyWJUb+YfMkL6RplnfXRVix8/5Fc+C7qHKzmdKo5Y4gDOJ+ 3coU4Y3V1OG2KybEjG/wLaR38gtHzJZU02zNzPgC4yTKLtWnyWb0lhzKO3Yty3Mfcvv0 lyYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:x-gm-message-state:from:to:cc; bh=30XQYa5vrUU1iEUJfeVFtkHZOATBPFqy9Zstl/P+5z8=; b=4147/9pIA/ZSbmaddkjXTd9ZgQOEcTOZf/9MS4tW0cm5YzhcoSNQKSlr2hqN+lvTJM OuNY7KJpLowkzSQKGlmxcbghjiezhjU2L2u8bLgpWizcf4gFtmLyqkOZ2AuS2AtN2UOn 0OEvQOMOPUO0HR8laNWbf90fjjoXfdUPM4Si/MqU8P9+y1OOA8dvMfg5ZPsPH9o1biGA qE8cHCxgrdwH5VFP4nxSQdNvcFS7N7R3FTbfKHVEwwZ08Eqj1sAvAVQA06dOF+crUgzF DqXrZ3J2uFvtNawJPXbXxh0SgeIdhyMHgigJJIboegUhV8XLx6FKEgN1y5907hmkVeBN Hybg== X-Gm-Message-State: ACgBeo2Gxsr2s7XqDbRTvsGVq99Kkx95puT+GXBu64kfs+Yu3RY/hTcl zNgsB34EfHQzk13fOGL/lEzyMu87eXc= X-Google-Smtp-Source: AA6agR6yQ+fa8aAJU91nirXEpLdJfvOKRCf8sGouwqrIk3ZQl0y+7CwvEhHK1EqDROOKe3AB5MwuoE4CU6hr X-Received: from jackyli.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3b51]) (user=jackyli job=sendgmr) by 2002:a17:90b:4b91:b0:1f4:e116:8f1 with SMTP id lr17-20020a17090b4b9100b001f4e11608f1mr870049pjb.121.1659466549678; Tue, 02 Aug 2022 11:55:49 -0700 (PDT) Date: Tue, 2 Aug 2022 18:55:33 +0000 In-Reply-To: <20220802185534.735338-1-jackyli@google.com> Message-Id: <20220802185534.735338-2-jackyli@google.com> Mime-Version: 1.0 References: <20220802185534.735338-1-jackyli@google.com> X-Mailer: git-send-email 2.37.1.455.g008518b4e5-goog Subject: [PATCH 1/2] crypto: ccp - Initialize PSP when reading psp data file failed From: Jacky Li To: Brijesh Singh , Tom Lendacky , John Allen Cc: Herbert Xu , "David S. Miller" , Marc Orr , Alper Gun , Peter Gonda , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Jacky Li Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Currently the OS fails the PSP initialization when the file specified at 'init_ex_path' does not exist or has invalid content. However the SEV spec just requires users to allocate 32KB of 0xFF in the file, which can be taken care of by the OS easily. To improve the robustness during the PSP init, leverage the retry mechanism and continue the init process: During the first INIT_EX call, if the content is invalid or missing, continue the process by feeding those contents into PSP instead of aborting. PSP will then override it with 32KB 0xFF and return SEV_RET_SECURE_DATA_INVALID status code. In the second INIT_EX call, this 32KB 0xFF content will then be fed and PSP will write the valid data to the file. In order to do this, it's also needed to skip the sev_read_init_ex_file in the second INIT_EX call to prevent the file content from being overwritten by the 32KB 0xFF data provided by PSP in the first INIT_EX call. Co-developed-by: Peter Gonda Signed-off-by: Peter Gonda Signed-off-by: Jacky Li Reported-by: Alper Gun --- .../virt/kvm/x86/amd-memory-encryption.rst | 5 ++-- drivers/crypto/ccp/sev-dev.c | 29 +++++++++++++------ 2 files changed, 22 insertions(+), 12 deletions(-) diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documen= tation/virt/kvm/x86/amd-memory-encryption.rst index 2d307811978c..935aaeb97fe6 100644 --- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst @@ -89,9 +89,8 @@ context. In a typical workflow, this command should be th= e first command issued. =20 The firmware can be initialized either by using its own non-volatile stora= ge or the OS can manage the NV storage for the firmware using the module paramet= er -``init_ex_path``. The file specified by ``init_ex_path`` must exist. To cr= eate -a new NV storage file allocate the file with 32KB bytes of 0xFF as require= d by -the SEV spec. +``init_ex_path``. If the file specified by ``init_ex_path`` does not exist= or +is invalid, the OS will create or override the file with output from PSP. =20 Returns: 0 on success, -negative on error =20 diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index 799b476fc3e8..5bb2ae250d38 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -75,6 +75,7 @@ static void *sev_es_tmr; */ #define NV_LENGTH (32 * 1024) static void *sev_init_ex_buffer; +static bool nv_file_loaded; =20 static inline bool sev_version_greater_or_equal(u8 maj, u8 min) { @@ -211,18 +212,19 @@ static int sev_read_init_ex_file(void) if (IS_ERR(fp)) { int ret =3D PTR_ERR(fp); =20 - dev_err(sev->dev, - "SEV: could not open %s for read, error %d\n", - init_ex_path, ret); + if (ret !=3D -ENOENT) { + dev_err(sev->dev, + "SEV: could not open %s for read, error %d\n", + init_ex_path, ret); + } return ret; } =20 nread =3D kernel_read(fp, sev_init_ex_buffer, NV_LENGTH, NULL); if (nread !=3D NV_LENGTH) { - dev_err(sev->dev, - "SEV: failed to read %u bytes to non volatile memory area, ret %ld\n", + dev_info(sev->dev, + "SEV: could not read %u bytes to non volatile memory area, ret %ld\n", NV_LENGTH, nread); - return -EIO; } =20 dev_dbg(sev->dev, "SEV: read %ld bytes from NV file\n", nread); @@ -417,9 +419,18 @@ static int __sev_init_ex_locked(int *error) data.nv_address =3D __psp_pa(sev_init_ex_buffer); data.nv_len =3D NV_LENGTH; =20 - ret =3D sev_read_init_ex_file(); - if (ret) - return ret; + /* + * The caller of INIT_EX will retry if it fails. Furthermore, if the + * failure is due to sev_init_ex_buffer being invalid, the PSP will have + * properly initialized the buffer already. Therefore, do not initialize + * it a second time. + */ + if (!nv_file_loaded) { + ret =3D sev_read_init_ex_file(); + if (ret && ret !=3D -ENOENT) + return ret; + nv_file_loaded =3D true; + } =20 if (sev_es_tmr) { /* --=20 2.37.1.455.g008518b4e5-goog From nobody Sun Apr 12 00:53:18 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 260E2C19F29 for ; Tue, 2 Aug 2022 18:56:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230254AbiHBS4J (ORCPT ); Tue, 2 Aug 2022 14:56:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230347AbiHBSzx (ORCPT ); Tue, 2 Aug 2022 14:55:53 -0400 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B982A140CB for ; Tue, 2 Aug 2022 11:55:52 -0700 (PDT) Received: by mail-pj1-x1049.google.com with SMTP id 1-20020a17090a190100b001f05565f004so6539286pjg.0 for ; Tue, 02 Aug 2022 11:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:from:to:cc; bh=DaRQ2izucvqnfyvR2TmA8t9g6dOpwwmSS0DB8AAt990=; b=Ly/T2amXaGhpFs2B6F33kLC4xhEqMWV/njDT98eEk+lNKHotckSXgbK21dcXaRSkEJ xC4TY/pNLC0vKpjDH+hWyM/8Z5B509hJThDN0jNXjV1sIfFO1tIamw71iNskhvacGwXV dNKqw6o07cOIHW3GzxTWOIPg3BuCP9Mqu7z7XruKYJrZ6z0gc5FVfJKTGkVGLORTfSfo 6hIaTTFDAMJtB/Upablei5j9czw7XRYowNd3SzztxYpfPdBQw5IDAM2Hb90NJx2QANVi WAW5/rZm+PxZmTV2nYO6O88EaUfncGhGnRn55ABJKqvwFrgAmkS+14oZlQLEuNedYMbf JCFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:x-gm-message-state:from:to:cc; bh=DaRQ2izucvqnfyvR2TmA8t9g6dOpwwmSS0DB8AAt990=; b=jaLpAoGaqFNLwknhVAg/uNby6ZYAToisIvgIyWLXrrg5eFHXaM4M1aJWeUwt6ABIUZ ZOn9vMKhH1X7OFd2py0uK9bzhs4JuKbPei32VMgOibbLp8fsqCHac4dUr8UBhmXfSxmj kgTOkV79yBjKW6GOPhWVc4argvVOPb77P/BulFY2uh9DVf4JHfsA2AFytbMCWphCEWld G3fpHCxK8OsrzYIUf1ejOVu9Ti9KYwVKU72YLM1uX5fyenmoOrTXP8FNqF7vvTNreq6h bw7ORcMxojB6TAzo6S6dO05Hvq3h8+TtJ6HX3Oyw23PCCmVgH8l/Bebo8UvLKC0yTiNh zsNw== X-Gm-Message-State: AJIora875V5V7qfqfYEdC5EJ3vIoQLQSYrcNpi2Er7bYBahd9Brxr8gU kKV6h9XIMa9MCCKEzZKH/3gflV8QI/I= X-Google-Smtp-Source: AGRyM1sWB3iGMjsNkKLdcbRYMAQl1qXz8lJEvDNwsSlg1g42TIIMXnJD1yEZwFLFr4gUcVdMpKbsvK5T7XDO X-Received: from jackyli.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3b51]) (user=jackyli job=sendgmr) by 2002:a63:43c2:0:b0:41a:9dea:5dac with SMTP id q185-20020a6343c2000000b0041a9dea5dacmr17694202pga.585.1659466552250; Tue, 02 Aug 2022 11:55:52 -0700 (PDT) Date: Tue, 2 Aug 2022 18:55:34 +0000 In-Reply-To: <20220802185534.735338-1-jackyli@google.com> Message-Id: <20220802185534.735338-3-jackyli@google.com> Mime-Version: 1.0 References: <20220802185534.735338-1-jackyli@google.com> X-Mailer: git-send-email 2.37.1.455.g008518b4e5-goog Subject: [PATCH 2/2] crypto: ccp - Fail the PSP initialization when writing psp data file failed From: Jacky Li To: Brijesh Singh , Tom Lendacky , John Allen Cc: Herbert Xu , "David S. Miller" , Marc Orr , Alper Gun , Peter Gonda , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Jacky Li Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Currently the OS continues the PSP initialization when there is a write failure to the init_ex_file. Therefore, the userspace would be told that SEV is properly INIT'd even though the psp data file is not updated. This is problematic because later when asked for the SEV data, the OS won't be able to provide it. Fixes: 3d725965f836 ("crypto: ccp - Add SEV_INIT_EX support") Reported-by: Peter Gonda Signed-off-by: Jacky Li Reported-by: kernel test robot --- drivers/crypto/ccp/sev-dev.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index 5bb2ae250d38..fd6bb01eb198 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -233,7 +233,7 @@ static int sev_read_init_ex_file(void) return 0; } =20 -static void sev_write_init_ex_file(void) +static int sev_write_init_ex_file(void) { struct sev_device *sev =3D psp_master->sev_data; struct file *fp; @@ -243,14 +243,15 @@ static void sev_write_init_ex_file(void) lockdep_assert_held(&sev_cmd_mutex); =20 if (!sev_init_ex_buffer) - return; + return 0; =20 fp =3D open_file_as_root(init_ex_path, O_CREAT | O_WRONLY, 0600); if (IS_ERR(fp)) { + int ret =3D PTR_ERR(fp); dev_err(sev->dev, "SEV: could not open file for write, error %ld\n", - PTR_ERR(fp)); - return; + ret); + return ret; } =20 nwrite =3D kernel_write(fp, sev_init_ex_buffer, NV_LENGTH, &offset); @@ -261,18 +262,20 @@ static void sev_write_init_ex_file(void) dev_err(sev->dev, "SEV: failed to write %u bytes to non volatile memory area, ret %ld\n", NV_LENGTH, nwrite); - return; + return -EIO; } =20 dev_dbg(sev->dev, "SEV: write successful to NV file\n"); + + return 0; } =20 -static void sev_write_init_ex_file_if_required(int cmd_id) +static int sev_write_init_ex_file_if_required(int cmd_id) { lockdep_assert_held(&sev_cmd_mutex); =20 if (!sev_init_ex_buffer) - return; + return 0; =20 /* * Only a few platform commands modify the SPI/NV area, but none of the @@ -287,10 +290,10 @@ static void sev_write_init_ex_file_if_required(int cm= d_id) case SEV_CMD_PEK_GEN: break; default: - return; + return 0; } =20 - sev_write_init_ex_file(); + return sev_write_init_ex_file(); } =20 static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret) @@ -363,7 +366,7 @@ static int __sev_do_cmd_locked(int cmd, void *data, int= *psp_ret) cmd, reg & PSP_CMDRESP_ERR_MASK); ret =3D -EIO; } else { - sev_write_init_ex_file_if_required(cmd); + ret =3D sev_write_init_ex_file_if_required(cmd); } =20 print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data, --=20 2.37.1.455.g008518b4e5-goog