Received: by 2002:a05:6358:795:b0:dc:4c66:fc3e with SMTP id n21csp1069984rwj; Sat, 29 Oct 2022 16:20:31 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7DB7sy4sETfkMj8ojKIkuRozsGYfgibrWXhVoKy87V5Xc5uDEAlqoycLlLNaxqIwXD6lXm X-Received: by 2002:a17:907:c03:b0:781:fd5a:c093 with SMTP id ga3-20020a1709070c0300b00781fd5ac093mr5743110ejc.89.1667085631089; Sat, 29 Oct 2022 16:20:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667085631; cv=none; d=google.com; s=arc-20160816; b=AJWLvZ1FCjlhV4k7bDEfdz/Mot0hNGpVaohmE3m8slCJfUkOEQWikWyhMbDH+RoSQv 5Tm9s3N1qi62myrCYNt/fJFHcrNP7BOxr0oKvAl/Tg9P/DXSGSaZBBHPKJcGeXr63suy 0wlJK3emI9SWiJaorkYrbv9a1GggWsXDDlgXW3HnY1WlvUZRgsDpz0jkYBdxYLLI8Ns+ ms7oNIMy0thlTLLo4d7L4pQHqY5WQdc0rctyDnWd1tZz+rI34LG8AwWTFmKLBRRUsvda pYNRsEJgl7MdKBE5T9v+2iuLRQCxawHIdMRUnnBrYbaAdhS3fAxcWj+Ls9wZ9Y4UHUIJ YCyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=TbvGjahNQbIyd+eArYqdPtpGbtOOuKs800W4Y29hSjg=; b=V0QDVRV3rjLYOAgFefE/Hsal9SjmKCahGwKFqFdw46oIQYSfGiTV8WEvbfcib7xJTr e/Gfs/pJEPp+FVONMBhusLM9jsFn9l/jFYcp6F18USy22YK0kF2nSo72hy19+Xr1Qja9 7+/C+DgXp3h5qbTACe2AYN08qtGibddfQMBgoD6aGrOKvETCr/atCBgjXyUYSzX9JDi0 aCeEC26kRcjIZnf0N+vSj9B5vfVRJAe2tfJ8NFNLsGRvf2XGo9LLwBZfMGkR6gZbtwP9 rc4yrti48XD9WYaiQJKladVKGteRrs0HIhtNp8N3k/WKgy+9SQFp7aXwYcAME+8zActn f1lw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ixdTBnAq; 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=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e5-20020a50a685000000b0045d189ac60esi2849260edc.401.2022.10.29.16.20.06; Sat, 29 Oct 2022 16:20:31 -0700 (PDT) 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=@intel.com header.s=Intel header.b=ixdTBnAq; 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=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229746AbiJ2XRt (ORCPT + 99 others); Sat, 29 Oct 2022 19:17:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbiJ2XRl (ORCPT ); Sat, 29 Oct 2022 19:17:41 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DCC732EF73; Sat, 29 Oct 2022 16:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667085460; x=1698621460; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=ZWyz83Ng/7FZvaGgwW6td6tKaOxX5oJfVXpiK7HPDLo=; b=ixdTBnAqrVBC0YM0QkR5j+o7ThlKB3eac26qulLMOJWZJS0+1BerEJu3 w9rtX31yZEGY6QhWpYZcegeGc9zHIdr6FyOwCvWN72cd9V3X8EFJiJJ+G AJMj2Aqy/NpQHc0VSvo3TlBpiZXE7+cJcGuCXZ79aLfTwdAgJ+TTlB9Qq TirCwi+uNR4Mw2g22Z+sGCHoMKvujJZTko27hbpn3SiNZ4lW5pRnjK4+W HVLRRLfDpPqNl1cDk6ycB4dG0mP2OIgdplKCFM3/alsZbN9N+q+cXLSu6 3SJpwLDmm4F4m8czzbYpWp+n9apdGAStuADrUYWpvOqi20EI5+IQyWCrl A==; X-IronPort-AV: E=McAfee;i="6500,9779,10515"; a="289093934" X-IronPort-AV: E=Sophos;i="5.95,224,1661842800"; d="scan'208";a="289093934" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2022 16:17:40 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10515"; a="664388070" X-IronPort-AV: E=Sophos;i="5.95,224,1661842800"; d="scan'208";a="664388070" Received: from guangna1-mobl.amr.corp.intel.com (HELO [10.209.109.108]) ([10.209.109.108]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2022 16:17:39 -0700 Message-ID: <01f437c1-9330-6fb5-d692-6cd500d8adf8@linux.intel.com> Date: Sat, 29 Oct 2022 16:17:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.2.2 Subject: Re: [PATCH v16 2/3] virt: Add TDX guest driver Content-Language: en-US To: Greg Kroah-Hartman Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Shuah Khan , Jonathan Corbet , "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Kai Huang , Wander Lairson Costa , Isaku Yamahata , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org References: <20221028002820.3303030-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20221028002820.3303030-3-sathyanarayanan.kuppuswamy@linux.intel.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE 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 Hi Greg On 10/27/22 11:25 PM, Greg Kroah-Hartman wrote: > On Thu, Oct 27, 2022 at 05:28:19PM -0700, Kuppuswamy Sathyanarayanan wrote: >> + >> +static long tdx_guest_ioctl(struct file *file, unsigned int cmd, >> + unsigned long arg) >> +{ >> + switch (cmd) { >> + case TDX_CMD_GET_REPORT: >> + return tdx_get_report((void __user *)arg); > > You know the type of this pointer here, why not cast it instead of > having to cast it from void * again? The only place we use arg pointer is in copy_from_user() function, which expects void __user * pointer. So why cast it as struct tdx_report_req * here? >> + >> +MODULE_AUTHOR("Kuppuswamy Sathyanarayanan "); >> +MODULE_DESCRIPTION("TDX Guest Driver"); >> +MODULE_LICENSE("GPL"); >> diff --git a/include/uapi/linux/tdx-guest.h b/include/uapi/linux/tdx-guest.h >> new file mode 100644 >> index 000000000000..29453e6a7ced >> --- /dev/null >> +++ b/include/uapi/linux/tdx-guest.h >> @@ -0,0 +1,55 @@ >> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ >> +/* >> + * Userspace interface for TDX guest driver >> + * >> + * Copyright (C) 2022 Intel Corporation >> + */ >> + >> +#ifndef _UAPI_LINUX_TDX_GUEST_H_ >> +#define _UAPI_LINUX_TDX_GUEST_H_ >> + >> +#include >> +#include >> + >> +/* Length of the REPORTDATA used in TDG.MR.REPORT TDCALL */ >> +#define TDX_REPORTDATA_LEN 64 >> + >> +/* Length of TDREPORT used in TDG.MR.REPORT TDCALL */ >> +#define TDX_REPORT_LEN 1024 > > As these are fixed values, why do you have to say them again in the > structure? These length recommendations are provided by the TDX Module, and there is a slight possibility that the TDX Module will increase the maximum size of the REPORTDATA and TDREPORT in the future. To handle such length changes, rather than inventing a new IOCTL for it in the future, making the current one flexible to handle such changes seems better. One less ABI to maintain is always better, right? My initial design did use fixed size buffers like you have recommended, but later changed it as per review suggestion to make the ABI flexible. > > If you ever change them, wonderful, make a new ioctl. You can't change > this one as userspace would have to also change, there is no way you > could mix/match kernel versions and userspace and not have problems. Removing the length based checks in the kernel (in tdx_get_report()) and directly passing the user input to the TDX Module can also avoid the usespace/kernel version mix/match issues you have mentioned. Does such a solution acceptable? > > So just fix these values, like you have, and remove them from the > structure definition as there's no way you can change them anyway. > With above details, if you think it is still better to remove the length params, I can make the change. >> + >> +/** >> + * struct tdx_report_req - Request struct for TDX_CMD_GET_REPORT IOCTL. >> + * >> + * @reportdata: User-defined REPORTDATA to be included into TDREPORT. >> + * Typically it can be some nonce provided by attestation >> + * service, so the generated TDREPORT can be uniquely verified. >> + * @tdreport: TDREPORT output from TDCALL[TDG.MR.REPORT]. > > These are userspace pointers, document them as such please. Will following change do? @reportdata: Address of the user buffer with user-defined REPORTDATA to be included into TDREPORT. @tdreport: Address of the user buffer to store TDREPORT output from TDCALL[TDG.MR.REPORT] > > thanks, > > greg k-h -- Sathyanarayanan Kuppuswamy Linux Kernel Developer