Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp520371pxh; Tue, 9 Nov 2021 14:36:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJxAxY7PgjfRl+7YpKpFsTWyzy1GrU+JUofW19qwdYLmrVfDlk2uuc3fPTVCgFOM83a6o+B8 X-Received: by 2002:a5d:860a:: with SMTP id f10mr7506935iol.142.1636497402951; Tue, 09 Nov 2021 14:36:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636497402; cv=none; d=google.com; s=arc-20160816; b=Jmaqpn6dASKqXoNY5oI+qt/D2/zN1h/YIxpHAAQiJSbfyxtB4UGfIYn15bT9hHJIkU ElovrJeAlzhp/5ioskjj/DNBswELd+P0c0AqglkEbWa6rCNeZDS3h3RKN2jyG0EuFdcm tWelIAWwKC3Tiw1JJs35E/SqjQ56wxTPVs5BrOnkMjc5GrJG3xZe+sQ8dJAOU9rez3F0 ZT0wcGt/g2sqVlTf8qg2+4rJ3LHiWhuAeO81nYGg7Y1A1zpHMryuXIapMQxAN+7XKuBh qUrQ9OJUSBrir/LrB15mK+XeUb8/Pnysqc1iMyq/oHHvImCmjxDGfR2zVX8TNfIXRrWX 8h1w== 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=+DobYMn9JpQ+enw2TdOzWV1L7zxSGklfH9GxpMYDKho=; b=UcD8+wEln/wIoSwvQfyPTgIUeuvYu1AApWILbPaf70l8EtLwS5Unk9SZGPGUZdhDwB Imlaha45HucbyQrKXZ+zhA5zDA1bFDarR29rWvoK6/WEzpRYvF+Da6qm6RK1d98qwVso mWAys41ivJ0hf22p0kRq3lKr90Q4W9vdFvZSSBsOD2gbBNs3UI3nk6q2w72QhmCSzHfl RC31CS+ip9ortaEyHZ1myEqUpoZKLVjhAoteqwkSwE1TurnakrtVtH7IRptdNNEJ1O3M GGbfMkmEpaVEkrIPj69xBEiggG144L+e1jA9jwye+8HTUF15YADTdIIAUKImYpz7NSq9 gFVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sxk0uFKM; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s4si30843774ilt.79.2021.11.09.14.36.24; Tue, 09 Nov 2021 14:36:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=sxk0uFKM; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-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 S240408AbhKIQtn (ORCPT + 99 others); Tue, 9 Nov 2021 11:49:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240345AbhKIQtk (ORCPT ); Tue, 9 Nov 2021 11:49:40 -0500 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED8CFC0613F5 for ; Tue, 9 Nov 2021 08:46:53 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id z34so2675918lfu.8 for ; Tue, 09 Nov 2021 08:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+DobYMn9JpQ+enw2TdOzWV1L7zxSGklfH9GxpMYDKho=; b=sxk0uFKMhwTn+CM8H0CHltcLP+zx3SB/DVLc3/ZV2EpxzoTwd7i/FFmTKgom2vg7Cy 84XnO+mOHJMUaFVLaMVN9Yyblxw95Cm5gf9awuPaTvDxYJFiMi06wWFYcAtYDuCpSqpf hy4T4mw9dbtUQMZf3oPlvXWSRKr6vEn1Jz0LoOUXMlI51YBsAdVlXEJv6QQ5XujJeCzf MDxETFpwUsvt+SnIxvaK/7gYyvz+QwoU617eZKQfoEkBt3+uWNn6rNz3j3wdRHOpyaGE vR93EOuUspGrqdNIl6I9aJXXT9YUcp4/dhTaKG97bZFdKLAIDZYaWT+FApSy0L+jRjxK VBzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+DobYMn9JpQ+enw2TdOzWV1L7zxSGklfH9GxpMYDKho=; b=3mg/lU1qcDClvaKMKyZprSZFyMwpx1PTewAT01a+GPcnRLzleMbT3hTxbDSRd31iw2 29hjSeBH+HY+CSP3UI/pDSH2lbc2q6jrG+LHSc9qZhVuBBhv9ZagpHLhqbWJZ92/N2P3 ddkB0z7Xfd5hpUBglgyWzbldv02c5sXQ4j7nqp/vtXiTPCCkvec98s9vsYEd9EzHEOuR MzkQ1j/I04ewOAbDH6e7f5YuqAnc+1BKU5e1LGYTxS5brCMA+yAKmjIAm3b6E9qd/GDD 2p/9+Bxrl1keI7AunYabzcGuckr/l9q5BGWt/WzsVUapag6sv4TjAgGShqQZ58dBpAAC qyNw== X-Gm-Message-State: AOAM533IVx6TGwZpFfma+DeckEXv9sZgrs0Uip7QQliJCAi6k5Qu+RP6 1oNh5/g2zZ3YzxnJgai0feLS8KNSnHYaK1DtATzJjQ== X-Received: by 2002:a19:ad4d:: with SMTP id s13mr8364668lfd.373.1636476412095; Tue, 09 Nov 2021 08:46:52 -0800 (PST) MIME-Version: 1.0 References: <20211102142331.3753798-1-pgonda@google.com> <20211102142331.3753798-2-pgonda@google.com> In-Reply-To: From: Peter Gonda Date: Tue, 9 Nov 2021 09:46:40 -0700 Message-ID: Subject: Re: [PATCH V3 1/4] crypto: ccp - Fix SEV_INIT error logging on init To: Sean Christopherson Cc: Thomas.Lendacky@amd.com, Marc Orr , David Rientjes , Brijesh Singh , Joerg Roedel , Herbert Xu , John Allen , "David S. Miller" , Paolo Bonzini , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Nov 9, 2021 at 9:27 AM Sean Christopherson wrote: > > On Tue, Nov 02, 2021, Peter Gonda wrote: > > Currently only the firmware error code is printed. This is incomplete > > and also incorrect as error cases exists where the firmware is never > > called and therefore does not set an error code. This change zeros the > > firmware error code in case the call does not get that far and prints > > the return code for non firmware errors. > > > > Signed-off-by: Peter Gonda > > Reviewed-by: Marc Orr > > Acked-by: David Rientjes > > Acked-by: Tom Lendacky > > Cc: Tom Lendacky > > Cc: Brijesh Singh > > Cc: Marc Orr > > Cc: Joerg Roedel > > Cc: Herbert Xu > > Cc: David Rientjes > > Cc: John Allen > > Cc: "David S. Miller" > > Cc: Paolo Bonzini > > Cc: linux-crypto@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > --- > > drivers/crypto/ccp/sev-dev.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c > > index 2ecb0e1f65d8..ec89a82ba267 100644 > > --- a/drivers/crypto/ccp/sev-dev.c > > +++ b/drivers/crypto/ccp/sev-dev.c > > @@ -1065,7 +1065,7 @@ void sev_pci_init(void) > > { > > struct sev_device *sev = psp_master->sev_data; > > struct page *tmr_page; > > - int error, rc; > > + int error = 0, rc; > > Wouldn't it be more appropriate to use something the PSP can't return, e.g. -1? > '0' is SEV_RET_SUCCESS, which is quite misleading, e.g. the below error message > will print > > SEV: failed to INIT error 0, rc -16 > > which a bit head scratching without looking at the code. AFAICT, the PSP return > codes aren't intrinsically hex, so printing error as a signed demical and thus > > SEV: failed to INIT error -1, rc -16 > > would be less confusing. > > And IMO requiring the caller to initialize error is will be neverending game of > whack-a-mole. E.g. sev_ioctl() fails to set "error" in the userspace structure, > and literally every function exposed via include/linux/psp-sev.h has this same > issue. Case in point, the retry path fails to re-initialize "error" and will > display stale information if the second sev_platform_init() fails without reaching > the PSP. OK I can update __sev_platform_init_locked() to set error to -1. That seems pretty reasonable. Tom, is that OK with you? > > rc = sev_platform_init(&error); > if (rc && (error == SEV_RET_SECURE_DATA_INVALID)) { > /* > * INIT command returned an integrity check failure > * status code, meaning that firmware load and > * validation of SEV related persistent data has > * failed and persistent state has been erased. > * Retrying INIT command here should succeed. > */ > dev_dbg(sev->dev, "SEV: retrying INIT command"); > rc = sev_platform_init(&error); <------ error may or may not be set > } > > Ideally, error wouldn't be an output param and instead would be squished into the > true return value, but that'd required quite the refactoring, and might yield ugly > code generation on non-64-bit architectures (does this code support those?). > > As a minimal step toward sanity, sev_ioctl(), __sev_platform_init_locked(), and > __sev_do_cmd_locked() should initialize the incoming error. Long term, sev-dev > really needs to either have well-defined API for when "error" is meaningful, or > ensure the pointer is initialized in all paths. These comments seem fine to me. But I'll refrain from updating anything here since this seems out-of-scope of this series. Happy to discuss further and work on that if Tom is interested in those refactors too. > > E.g. > > diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c > index ec89a82ba267..549686a1e812 100644 > --- a/drivers/crypto/ccp/sev-dev.c > +++ b/drivers/crypto/ccp/sev-dev.c > @@ -149,6 +149,9 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret) > unsigned int reg, ret = 0; > int buf_len; > > + if (psp_ret) > + *psp_ret = -1; > + > if (!psp || !psp->sev_data) > return -ENODEV; > > @@ -192,9 +195,6 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret) > /* wait for command completion */ > ret = sev_wait_cmd_ioc(sev, ®, psp_timeout); > if (ret) { > - if (psp_ret) > - *psp_ret = 0; > - > dev_err(sev->dev, "sev command %#x timed out, disabling PSP\n", cmd); > psp_dead = true; > > @@ -243,6 +243,9 @@ static int __sev_platform_init_locked(int *error) > struct sev_device *sev; > int rc = 0; > > + if (error) > + *error = -1; > + > if (!psp || !psp->sev_data) > return -ENODEV; > > @@ -838,6 +841,8 @@ static long sev_ioctl(struct file *file, unsigned int ioctl, unsigned long arg) > if (input.cmd > SEV_MAX) > return -EINVAL; > > + input.error = -1; > + > mutex_lock(&sev_cmd_mutex); > > switch (input.cmd) { > > > if (!sev) > > return; > > @@ -1104,7 +1104,8 @@ void sev_pci_init(void) > > } > > > > if (rc) { > > - dev_err(sev->dev, "SEV: failed to INIT error %#x\n", error); > > + dev_err(sev->dev, "SEV: failed to INIT error %#x, rc %d\n", > > + error, rc); > > return; > > } > > > > -- > > 2.33.1.1089.g2158813163f-goog > >