Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp1054949rwn; Thu, 8 Sep 2022 12:39:01 -0700 (PDT) X-Google-Smtp-Source: AA6agR4eVnyIdflHlUYeEGXFcy8kSvcFmgcidFZ3LTb1J49twt3j0lroj/5XWUTUnfYGWJOdTF04 X-Received: by 2002:a17:902:ecce:b0:16e:e6e9:69ba with SMTP id a14-20020a170902ecce00b0016ee6e969bamr10620116plh.97.1662665941471; Thu, 08 Sep 2022 12:39:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662665941; cv=none; d=google.com; s=arc-20160816; b=MjH4M/q4OVQYm3A+nLH2TBDXNABfzqirVJGYWnFXzou5jDv0dxOrymqkjdc5HUR95O FAQaOwbufrJG6S7zTIMygF3l8ZEJNjqUgiLyvjcbR6HlFk6oX8OZR5hvn1QcokBPqk9K y1Bto5O3/xovNGhAcC1uxMV+vuprEUgTxcreSJzxP4UG7an++6GB3B9LgWxyoQpQSDKQ XVErkB37+s/ebWKb5nWqddW3HVkEcVzyNrazayw3jK5hi0CjGWElS5rBRsona63u2v+g IMJUItDHfP88jYw/HTttjuQG8IL6ES6dqcPum2hwLi/pJ4Vr6V08wOecHg5Hx8+qp9zS sTbg== 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=iyYM/pbczt4CoGaul5woCqujGkyXIJyq2hP4GUPlGfA=; b=akSJjC6IQNr6wHpRAdVZwpYKw1TT3XCOXM4ujXqI0XeCnVs/+FbQ0vtu9j6Jwkt8my eFlh8U+T3H/2eP1gQvXncV2kMeqJg9UC2jGN/C6Y7gVnmZJruTgphqYTMSXHg8S3kvPW mXIcnp4mv5rhtqjUrs9o+DonlZe+Mg0uUs0fY1gtfZdh1g82dvVRdfgkyW71ABfOHq5L ci8PxnSW/DP8L8yfsHRKtcN7mJa6Kzb021OmWQD1kY1NcnLirXo6U1fKBHFMRGi8Huek 6xdgFyjTVQT1CzuGboixDH0I3yVoBU5wTyftLDUKZQxcAOJV/oo7KJIOLVLUFjWlRcky YzcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=DZyFwN8Q; 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 199-20020a6302d0000000b00434277cd636si4357613pgc.414.2022.09.08.12.38.50; Thu, 08 Sep 2022 12:39:01 -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=DZyFwN8Q; 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 S231252AbiIHTHd (ORCPT + 99 others); Thu, 8 Sep 2022 15:07:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229610AbiIHTHb (ORCPT ); Thu, 8 Sep 2022 15:07:31 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6B5FC04F0; Thu, 8 Sep 2022 12:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662664049; x=1694200049; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=44eqfRb+CPq6+faXpY40ZoHvEwz6Mc0cnlewhnmlylc=; b=DZyFwN8QNY5TIO/4iunsaWHHkAY+Q/LdaD7+AnD9peGalPZdYpf0tbRC FIrQWYPL2VERFNzfNo822zlBd0ozO2It3AauduBEzmVKtyJfo4ARb41zM 65FsVtWmAHZtkOmlE/C8s/gx0Cm+bvsudxlJEQ4ht21qi4+WArK7mmLHM bLaqc21nYSLITbOrmsNs7yo76I8LKRM1kGsm8kfgqKJzTA9L3n/OTUEPJ G/Ah+NYSYsMcMw/D1RW55UtxlN3K+u3bWwEFrs4tVG538LiJBS7LYtf2D Obcms0TPLfYl5gheiJ4now0ccxrWKlmv7rZHqneetGfVNvlnaZCkzPTll g==; X-IronPort-AV: E=McAfee;i="6500,9779,10464"; a="277032673" X-IronPort-AV: E=Sophos;i="5.93,300,1654585200"; d="scan'208";a="277032673" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2022 12:07:29 -0700 X-IronPort-AV: E=Sophos;i="5.93,300,1654585200"; d="scan'208";a="740787532" Received: from duttamou-mobl1.amr.corp.intel.com (HELO [10.209.109.184]) ([10.209.109.184]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Sep 2022 12:07:28 -0700 Message-ID: <6cf407ed-95c7-0db4-d581-b85efad13239@linux.intel.com> Date: Thu, 8 Sep 2022 12:07:28 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.11.0 Subject: Re: [PATCH v12 1/3] x86/tdx: Add TDX Guest attestation interface driver Content-Language: en-US To: Greg Kroah-Hartman Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Shuah Khan , "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Andi Kleen , 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: <20220908002723.923241-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20220908002723.923241-2-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=-7.5 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_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE 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, On 9/7/22 10:31 PM, Greg Kroah-Hartman wrote: > On Wed, Sep 07, 2022 at 05:27:20PM -0700, Kuppuswamy Sathyanarayanan wrote: >> + /* >> + * Per TDX Module 1.0 specification, section titled >> + * "TDG.MR.REPORT", REPORTDATA length is fixed as >> + * TDX_REPORTDATA_LEN, TDREPORT length is fixed as >> + * TDX_REPORT_LEN, and TDREPORT subtype is fixed as >> + * 0. Also check for valid user pointers. >> + */ >> + if (!req.reportdata || !req.tdreport || req.subtype || >> + req.rpd_len != TDX_REPORTDATA_LEN || >> + req.tdr_len != TDX_REPORT_LEN) >> + return -EINVAL; > > You never verify that your reserved[7] fields are actually set to 0, > which means you can never use them in the future :( Currently, we don't use those fields in our code. Why do we have to make sure they are set to zero? Can't we add checks when we really use them in future? If your suggestion is to define allowed values of these fields for user, we can add some help in structure definition of "tdx_report_req" in arch/x86/include/uapi/asm/tdx.h > > Please fix that up, thanks. > > greg k-h -- Sathyanarayanan Kuppuswamy Linux Kernel Developer