Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp3838354rwb; Sat, 3 Dec 2022 11:54:07 -0800 (PST) X-Google-Smtp-Source: AA0mqf6nLczFJGzy4sGyt7O/ItbH7ASJANvn/Tyh8pPbwV2rdXjOpiiIZQJKyzR0tFsZTjqxps2T X-Received: by 2002:a17:906:4889:b0:7bc:42f6:372e with SMTP id v9-20020a170906488900b007bc42f6372emr35798899ejq.662.1670097247070; Sat, 03 Dec 2022 11:54:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670097247; cv=none; d=google.com; s=arc-20160816; b=cm4CgAGNYo93lBYWEqbjS+A5x6tDTySjZ6aQUW7O+YpyodScevY2EI8af1XgbwnS5B nduIcozUCJxYwIi+UFifwgPNyJV8e576W/gw+1nZtMnNlx92jCfqYcO7YljQY+uLf+vj fHxcGKKtZKnrv4H6XZu7lI0bvuFGaPRA0g2vOXqTq1AjhxtimW29TU65kZTyRUABZvRL vq/XZhTDHphl54TU2qLwlTbHZWPG7iVtbNlYweq0MY5b4e5qujuROOYQkdfeyf6IEmbY rejiqRXUdcJQr5AoZrpDeffImHz6+jRot0YfqU1sOf5tBdCz4wwkH+UZGm7+1QYvOqLu v0wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=iggn9NGaBvUPIp9zkjxeRVT+n0l+Sec5shJh8MQOX88=; b=PNrbP6/OcrDuw72+uuH01YST646aQfU+OYMsEXfKZt4fIVB/epMDIn48EOfFlkkkcx Z4YPYu/VzQVjWqXgw8y1j0yxDMV3yV0gtrBdf7bHb81MAU9/xIjqTh99c5pufvsEh7Hx lA0JDVxt/VovNU87bOkuNKqfz8+HOu1mnCJCA5rzq2erzBo5HwK8vzwcJaEP9+59+roe gg54QwevwyjdIG7PHt4Y980j5/AWcXZWL4zBFa/zYF4Uzb+TLB8AfNS35CsHxbI5x+4Q yjDgrUSPWwT0ub8mNG/WW/wsKonnlhBZO2YUP3SBNxiZKotR0L9LEgcZMH0TPIxU08UY weQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bETcumAG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id co20-20020a0564020c1400b0046bb45ce1a6si8570983edb.405.2022.12.03.11.53.38; Sat, 03 Dec 2022 11:54:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bETcumAG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229680AbiLCS6y (ORCPT + 82 others); Sat, 3 Dec 2022 13:58:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229502AbiLCS6w (ORCPT ); Sat, 3 Dec 2022 13:58:52 -0500 Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57A7E65D7 for ; Sat, 3 Dec 2022 10:58:51 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id db10-20020a0568306b0a00b0066d43e80118so4895106otb.1 for ; Sat, 03 Dec 2022 10:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iggn9NGaBvUPIp9zkjxeRVT+n0l+Sec5shJh8MQOX88=; b=bETcumAGBoOkqCscoCWsAb9+VL8QJ4WYzfM9YwIbtFnxZZnkdzXkQxqkPkEiml3UNy 6MpGfVPEY+7rdGbUDRxefD5L58gMWHc4si8wf6AEEq2BMSG+epZ4HsB00jsUwuTm+wqi PAnXWifpVnXZN5sF4d+IxF47CM2FUnvhsZ+T7mRTwX36xRp7cyU3bT1W8jDsQMok4w0p rXs9lGaYMBcMFl19X33SZi2cdbQoSHzM137/zszlECFS500PSW0NWc6/33CEpP0y/5j6 EaM7gSjx13boV272Qa8+6uybZFSPzDSOua/IVIFP///a48XSLEJcJynuHMtAMqGF3mLM X4zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iggn9NGaBvUPIp9zkjxeRVT+n0l+Sec5shJh8MQOX88=; b=iwQzsJpwjhLRRnUHVpJQ6p6uLtYYvXe/3Oo2tE55wSrUoFYz+qdZUaHe1lffTwm8LJ mzStlptTvsLIDNuwKGRAQ9o5Zl2GpoaRL3KQ1nKGKH7ZtdTAq17gsAQWDDdJ7GCDIlTT xuIANabNRLSJiPPxHeNTfS1mfZg0NW65URPIhnU0wklDwNFCrWbfqBm40OL3uPOnRSTc xKVUyJxkUWFTaZJ/RUCdTLmRTN/gVUau4ApBcb+ZjY6X8nkV7aHrbDHlJ1GJgHAbyiiG gA4uoAzHhm2NDZFuvj8YcG/KxyIHt4gKk8InYrQbPmIUEzGrsKdE8nZkpNTqpmv3UvNE zUxQ== X-Gm-Message-State: ANoB5pl7L91xpR4Z8UZ0vsGwmy5bUTkijWobRIfXPIE/H4w3dRTk0cft bwSzdKSTBkzwF1fCpWSGfILhLwrtYhy/ysF7PfSb9g== X-Received: by 2002:a9d:6e19:0:b0:66c:a613:9804 with SMTP id e25-20020a9d6e19000000b0066ca6139804mr37375296otr.65.1670093930526; Sat, 03 Dec 2022 10:58:50 -0800 (PST) MIME-Version: 1.0 References: <20221104230040.2346862-1-dionnaglaze@google.com> <20221104230040.2346862-2-dionnaglaze@google.com> In-Reply-To: From: Dionna Amalie Glaze Date: Sat, 3 Dec 2022 10:58:39 -0800 Message-ID: Subject: Re: [PATCH v8 1/4] crypto: ccp - Name -1 return value as SEV_RET_NO_FW_CALL To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Peter Gonda , Thomas Lendacky , Paolo Bonzini , Joerg Roedel , Ingo Molnar , Andy Lutomirsky , John Allen , Herbert Xu , "David S. Miller" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 3, 2022 at 4:26 AM Borislav Petkov wrote: > > On Fri, Nov 04, 2022 at 11:00:37PM +0000, Dionna Glaze wrote: > > From: Peter Gonda > > > > The PSP can return a "firmware error" code of -1 in circumstances where > > the PSP is not actually called. To make this protocol unambiguous, we > > Please use passive voice in your commit message: no "we" or "I", etc, > and describe your changes in imperative mood. > > > add a constant naming the return value. > > > > Cc: Thomas Lendacky > > Cc: Paolo Bonzini > > Cc: Joerg Roedel > > Cc: Ingo Molnar > > Cc: Andy Lutomirsky > > Cc: John Allen > > Cc: Herbert Xu > > Cc: "David S. Miller" > > > > Signed-off-by: Peter Gonda > > Signed-off-by: Dionna Glaze > > --- > > drivers/crypto/ccp/sev-dev.c | 2 +- > > include/uapi/linux/psp-sev.h | 7 +++++++ > > 2 files changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c > > index 06fc7156c04f..97eb3544ab36 100644 > > --- a/drivers/crypto/ccp/sev-dev.c > > +++ b/drivers/crypto/ccp/sev-dev.c > > @@ -444,7 +444,7 @@ static int __sev_platform_init_locked(int *error) > > { > > struct psp_device *psp = psp_master; > > struct sev_device *sev; > > - int rc = 0, psp_ret = -1; > > + int rc = 0, psp_ret = SEV_RET_NO_FW_CALL; > > int (*init_function)(int *error); > > > > if (!psp || !psp->sev_data) > > Ok, lemme chase down this flow here: > > __sev_platform_init_locked() calls that automatic variable function > pointer ->init_function which already looks funky. See the end of this > mail for a diff removing it and making the code more readable. > I'm fine removing it if possible for the sev-dev.c code, but I'll still need the enum for the next patches in this series. I added it specifically because of the uninitialized memory problem with `err` that I witnessed in user space, and to replace the arbitrary 0xff value in existing code. > The called function can be one of two and both get the pointer to > psp_ret as its only argument. > > 1. __sev_init_ex_locked() calls __sev_do_cmd_locked() and passes down > *psp_ret. > > or > > 2. __sev_init_locked(). Ditto. > > Now, __sev_do_cmd_locked() will overwrite psp_ret when > sev_wait_cmd_ioc() fails. So far so good. It doesn't always overwrite psp_ret, such as the initial error checking. The value remains uninitialized for -ENODEV, -EBUSY, -EINVAL. Thus *error in __sev_platform_init_locked can be set to uninitialized memory if psp_ret is not first initialized. That error points to the kernel copy of the user's argument struct, which the ioctl always copies back. In the case of those error codes then, without SEV_RET_NO_FW_CALL, user space will get uninitialized kernel memory. > > In the case __sev_do_cmd_locked() succeeds, it'll put there something > else: > > if (psp_ret) > *psp_ret = reg & PSP_CMDRESP_ERR_MASK; > > So no caller will ever see SEV_RET_NO_FW_CALL, as far as I can tell. > > And looking further through the rest of the set, nothing tests > SEV_RET_NO_FW_CALL - it only gets assigned. > > So why are we even bothering with this? > > You can hand in *psp_ret uninitialized and you'll get a value in all > cases. Unless I'm missing an angle. > I think my above comment points out the wrinkle. > > diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h > > index 91b4c63d5cbf..1ad7f0a7e328 100644 > > --- a/include/uapi/linux/psp-sev.h > > +++ b/include/uapi/linux/psp-sev.h > > @@ -36,6 +36,13 @@ enum { > > * SEV Firmware status code > > */ > > typedef enum { > > + /* > > + * This error code is not in the SEV spec but is added to convey that > > + * there was an error that prevented the SEV Firmware from being called. > > + * This is (u32)-1 since the firmware error code is represented as a > > + * 32-bit integer. > > + */ > > + SEV_RET_NO_FW_CALL = 0xffffffff, > > What's wrong with having -1 here? > C++ brain not trusting what type enum has even in C. I can change it to -1. > > SEV_RET_SUCCESS = 0, > > SEV_RET_INVALID_PLATFORM_STATE, > > SEV_RET_INVALID_GUEST_STATE, > > -- > > diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c > index 97eb3544ab36..8bc4209b338b 100644 > --- a/drivers/crypto/ccp/sev-dev.c > +++ b/drivers/crypto/ccp/sev-dev.c > @@ -440,12 +440,20 @@ static int __sev_init_ex_locked(int *error) > return __sev_do_cmd_locked(SEV_CMD_INIT_EX, &data, error); > } > > +static inline int __sev_do_init_locked(int *psp_ret) > +{ > + if (sev_init_ex_buffer) > + return __sev_init_ex_locked(psp_ret); > + else > + > + return __sev_init_locked(psp_ret); > +} > + > static int __sev_platform_init_locked(int *error) > { > struct psp_device *psp = psp_master; > struct sev_device *sev; > - int rc = 0, psp_ret = SEV_RET_NO_FW_CALL; > - int (*init_function)(int *error); > + int rc = 0, psp_ret; > > if (!psp || !psp->sev_data) > return -ENODEV; > @@ -456,15 +464,12 @@ static int __sev_platform_init_locked(int *error) > return 0; > > if (sev_init_ex_buffer) { > - init_function = __sev_init_ex_locked; > rc = sev_read_init_ex_file(); > if (rc) > return rc; > - } else { > - init_function = __sev_init_locked; > } > > - rc = init_function(&psp_ret); > + rc = __sev_do_init_locked(&psp_ret); > if (rc && psp_ret == SEV_RET_SECURE_DATA_INVALID) { > /* > * Initialization command returned an integrity check failure > @@ -473,9 +478,12 @@ static int __sev_platform_init_locked(int *error) > * initialization function should succeed by replacing the state > * with a reset state. > */ > - dev_err(sev->dev, "SEV: retrying INIT command because of SECURE_DATA_INVALID error. Retrying once to reset PSP SEV state."); > - rc = init_function(&psp_ret); > + dev_err(sev->dev, > +"SEV: retrying INIT command because of SECURE_DATA_INVALID error. Retrying once to reset PSP SEV state."); > + > + rc = __sev_do_init_locked(&psp_ret); > } > + > if (error) > *error = psp_ret; > > diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h > index 1ad7f0a7e328..a9ed9e846cd2 100644 > --- a/include/uapi/linux/psp-sev.h > +++ b/include/uapi/linux/psp-sev.h > @@ -42,7 +42,7 @@ typedef enum { > * This is (u32)-1 since the firmware error code is represented as a > * 32-bit integer. > */ > - SEV_RET_NO_FW_CALL = 0xffffffff, > + SEV_RET_NO_FW_CALL = -1, > SEV_RET_SUCCESS = 0, > SEV_RET_INVALID_PLATFORM_STATE, > SEV_RET_INVALID_GUEST_STATE, > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette -- -Dionna Glaze, PhD (she/her)