Message ID | 20240109054604.2562620-1-sathyanarayanan.kuppuswamy@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-20413-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:37c1:b0:101:2151:f287 with SMTP id y1csp1459587dyq; Mon, 8 Jan 2024 21:47:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IH+L5kqrwwv1IJyj9TijZ536c0RIY70giJPaZaRy8QGdxG2EEYqC1h6zygUkgDYiKHMlroU X-Received: by 2002:ac2:4307:0:b0:50e:7fda:faa5 with SMTP id l7-20020ac24307000000b0050e7fdafaa5mr1690480lfh.88.1704779240270; Mon, 08 Jan 2024 21:47:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704779240; cv=none; d=google.com; s=arc-20160816; b=WDHTBu2zklG88l5QZHLA4gKe2+PnmJNEKX9D9oirbiT2obHHNiJnxOc0/F+d8uFORh ddC72zMxfRPbNfM6JsW5OUOpUZqaN74Rzu6PqFLZ+/bX1rVkONK5Oige0HC6b+t2IF4u p+H0dHSuJlI2iEED586CfCD+OeN1tXnO15i35ygMCy69AwJnlWIy2yxZkMlR34PXOtUY wXP/L7pc7MIzqFHeCejULFITgjiTmzeZpnFtyItkR6GHEoibxa5RZBAzyMURzRKOen8Z A5fYyOEJ4IBsaV682jyfTNygm20+1Dt5MQl7DhWEhsIVaj7+5n6lOTILdTDFUWPmLV1Y COog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=DSqpfnDusiSseXlLbyRyz56gO3w25ilwUofvCh96lX0=; fh=fHyqRWIV6DRZtyE6+pV3T+XZVT4is8eNsNQ8QFYiMIE=; b=nMwi2sXL5WBBAoZBnb0XMymG1l1apV+HWfaK0RXRoCo2q/GPsBb8sz3+a+ioKNpxv0 kVBLbu2DVVnvYYQpUET87PZ1ogrpHj5iDgRzMWDXnjzdG6Q9n5qqd+zRUGi8UJ1t65G8 /yq4QsjmuDLto4fyfCBzbaFylWQGyD03s5ZBpeJ2n9hki2xqfCm/7OV++9cBwawkEiWt eqqfof/tEeHfqjxATo/ktO0NLUWGjqH6GAilVChH7O64Ih+sT4ujpkrFgVJX4ouJ1c/4 x8XPFmpE9gmju6KBuaoqzyrftNbQ7SuyQN9kp2pd6XyHsT5Lg7Iz7ST8k/iRkQrd5mBo aYOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=chQqrlOs; spf=pass (google.com: domain of linux-kernel+bounces-20413-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-20413-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id t5-20020a170906a10500b00a28ea502d81si509417ejy.569.2024.01.08.21.47.20 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 21:47:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-20413-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=chQqrlOs; spf=pass (google.com: domain of linux-kernel+bounces-20413-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-20413-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id D9A381F246E1 for <ouuuleilei@gmail.com>; Tue, 9 Jan 2024 05:47:19 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 60E187476; Tue, 9 Jan 2024 05:47:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="chQqrlOs" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8A0F7EB8 for <linux-kernel@vger.kernel.org>; Tue, 9 Jan 2024 05:46:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704779219; x=1736315219; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=aGNHQNzRdrw4QB8auzJbZaFuYOreQI6Eh0B7R0TJOlA=; b=chQqrlOskyBLaX5E39ohFk/rJUPP5zLtQRb1CjN1etfKfdX/8ok+LwKK 7KkoV/6rnBhE9n+SR1ZNXl9pIPlUWuAVVjLk3uswCl5GkqKuKXxm6PX+K /UnSQHyZsbIn7rjo4trVkseGDPsLF0tBSBSP0lGeWxvT6Ct5/qP5LTI1X bxMvEzkooo2GHV73rErJ8PAyLk/NG5u5NW7iuD5tN+HlK4GPZ8gkyCXrp GK10Sq9CQt+K3IjBht40mJ1nQ868DSHag00yDsh67eFELkSa8FIMccUa7 r/4LVaTCThogT1BIDnyo3Hz1k0BQ6QT3Wg7fyQ5Ty6KB0X8LZ23LjI89r g==; X-IronPort-AV: E=McAfee;i="6600,9927,10947"; a="5457594" X-IronPort-AV: E=Sophos;i="6.04,181,1695711600"; d="scan'208";a="5457594" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2024 21:46:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10947"; a="905034325" X-IronPort-AV: E=Sophos;i="6.04,181,1695711600"; d="scan'208";a="905034325" Received: from skuppusw-desk2.jf.intel.com ([10.165.154.101]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2024 21:46:57 -0800 From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> To: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, x86@kernel.org Cc: Dave Hansen <dave.hansen@linux.intel.com>, Dan Williams <dan.j.williams@intel.com>, Xiaoyao Li <xiaoyao.li@intel.com>, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev Subject: [PATCH v1] virt: tdx-guest: Handle GetQuote request error code Date: Tue, 9 Jan 2024 05:46:04 +0000 Message-Id: <20240109054604.2562620-1-sathyanarayanan.kuppuswamy@linux.intel.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787590596574863025 X-GMAIL-MSGID: 1787590596574863025 |
Series |
[v1] virt: tdx-guest: Handle GetQuote request error code
|
|
Commit Message
Kuppuswamy Sathyanarayanan
Jan. 9, 2024, 5:46 a.m. UTC
Currently when a user requests for the Quote generation, the Quote
generation handler (tdx_report_new()) only checks whether the VMM
successfully processes the Quote generation request (status !=
GET_QUOTE_IN_FLIGHT) and returns the output to the user without
validating the status of the output data. Since VMM can return error
even after processing the Quote request, returning success just after
successful processing will create confusion to the user. Although for
the failed request, output buffer length will be zero and can also be
used by the user to identify the failure case, it will be more clear to
return error for all failed cases. So validate the Quote output status
and return error code for all failed cases.
Fixes: f4738f56d1dc ("virt: tdx-guest: Add Quote generation support using TSM_REPORTS")
Reported-by: Xiaoyao Li <xiaoyao.li@intel.com>
Closes: https://lore.kernel.org/linux-coco/6bdf569c-684a-4459-af7c-4430691804eb@linux.intel.com/T/#u
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
---
drivers/virt/coco/tdx-guest/tdx-guest.c | 6 ++++++
1 file changed, 6 insertions(+)
Comments
On Tue, Jan 09, 2024 at 05:46:04AM +0000, Kuppuswamy Sathyanarayanan wrote: > Currently when a user requests for the Quote generation, the Quote > generation handler (tdx_report_new()) only checks whether the VMM > successfully processes the Quote generation request (status != > GET_QUOTE_IN_FLIGHT) and returns the output to the user without > validating the status of the output data. Since VMM can return error > even after processing the Quote request, returning success just after > successful processing will create confusion to the user. Although for > the failed request, output buffer length will be zero and can also be > used by the user to identify the failure case, it will be more clear to > return error for all failed cases. So validate the Quote output status > and return error code for all failed cases. Could you split commit message into several paragraphs? It would be easier to get along. It can be helpful to follow structure like: <Background> <Problem> <Solution>
On 1/9/2024 5:17 AM, Kirill A . Shutemov wrote: > On Tue, Jan 09, 2024 at 05:46:04AM +0000, Kuppuswamy Sathyanarayanan wrote: >> Currently when a user requests for the Quote generation, the Quote >> generation handler (tdx_report_new()) only checks whether the VMM >> successfully processes the Quote generation request (status != >> GET_QUOTE_IN_FLIGHT) and returns the output to the user without >> validating the status of the output data. Since VMM can return error >> even after processing the Quote request, returning success just after >> successful processing will create confusion to the user. Although for >> the failed request, output buffer length will be zero and can also be >> used by the user to identify the failure case, it will be more clear to >> return error for all failed cases. So validate the Quote output status >> and return error code for all failed cases. > > Could you split commit message into several paragraphs? It would be easier > to get along. > > It can be helpful to follow structure like: > > <Background> > > <Problem> > > <Solution> > How about the following version? During the TDX guest attestation process, TSM ConfigFS ABI is used by the user attestation agent to get the signed VM measurement data (a.k.a Quote), which can be used by a remote verifier to validate the trustworthiness of the guest. When a user requests for the Quote data via the ConfigFS ABI, the TDX Quote generation handler (tdx_report_new()) forwards the request to VMM (or QE) via a hypercall, and then shares the output with the user. Currently, when handling the Quote generation request, tdx_report_new() handler only checks whether the VMM successfully processed the request and if it is true it returns success and shares the output to the user without actually validating the output data. Since the VMM can return error even after processing the Quote request, always returning success for the processed requests is incorrect and will create confusion to the user. Although for the failed request, output buffer length will be zero and can also be used by the user to identify the failure case, it will be more clear to return error for all failed cases. So when handling the Quote generation request, validate the Quote data output status and return error code for all failed cases.
On Tue, Jan 09, 2024 at 07:56:56PM -0800, Kuppuswamy Sathyanarayanan wrote: > > > On 1/9/2024 5:17 AM, Kirill A . Shutemov wrote: > > On Tue, Jan 09, 2024 at 05:46:04AM +0000, Kuppuswamy Sathyanarayanan wrote: > >> Currently when a user requests for the Quote generation, the Quote > >> generation handler (tdx_report_new()) only checks whether the VMM > >> successfully processes the Quote generation request (status != > >> GET_QUOTE_IN_FLIGHT) and returns the output to the user without > >> validating the status of the output data. Since VMM can return error > >> even after processing the Quote request, returning success just after > >> successful processing will create confusion to the user. Although for > >> the failed request, output buffer length will be zero and can also be > >> used by the user to identify the failure case, it will be more clear to > >> return error for all failed cases. So validate the Quote output status > >> and return error code for all failed cases. > > > > Could you split commit message into several paragraphs? It would be easier > > to get along. > > > > It can be helpful to follow structure like: > > > > <Background> > > > > <Problem> > > > > <Solution> > > > > How about the following version? > > During the TDX guest attestation process, TSM ConfigFS ABI is used by > the user attestation agent to get the signed VM measurement data (a.k.a > Quote), which can be used by a remote verifier to validate the > trustworthiness of the guest. When a user requests for the Quote data > via the ConfigFS ABI, the TDX Quote generation handler > (tdx_report_new()) forwards the request to VMM (or QE) via a hypercall, > and then shares the output with the user. > > Currently, when handling the Quote generation request, tdx_report_new() > handler only checks whether the VMM successfully processed the request > and if it is true it returns success and shares the output to the user > without actually validating the output data. Since the VMM can return > error even after processing the Quote request, always returning success > for the processed requests is incorrect and will create confusion to > the user. Although for the failed request, output buffer length will > be zero and can also be used by the user to identify the failure case, > it will be more clear to return error for all failed cases. > > So when handling the Quote generation request, validate the Quote data > output status and return error code for all failed cases. I would drop the start of the sentence upto ',' here, but otherwise looks good to me.
diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c index 1253bf76b570..61368318fa39 100644 --- a/drivers/virt/coco/tdx-guest/tdx-guest.c +++ b/drivers/virt/coco/tdx-guest/tdx-guest.c @@ -228,6 +228,12 @@ static int tdx_report_new(struct tsm_report *report, void *data) goto done; } + if (quote_buf->status != GET_QUOTE_SUCCESS) { + pr_err("GetQuote request failed, ret %llx\n", quote_buf->status); + ret = -EIO; + goto done; + } + buf = kvmemdup(quote_buf->data, quote_buf->out_len, GFP_KERNEL); if (!buf) { ret = -ENOMEM;