From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mx.groups.io with SMTP id smtpd.web09.2030.1573091941354464796 for ; Wed, 06 Nov 2019 17:59:01 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.126, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 17:59:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,276,1569308400"; d="scan'208";a="196402858" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga008.jf.intel.com with ESMTP; 06 Nov 2019 17:59:00 -0800 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 6 Nov 2019 17:59:00 -0800 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 6 Nov 2019 17:58:59 -0800 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 6 Nov 2019 17:58:59 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.127]) by SHSMSX153.ccr.corp.intel.com ([169.254.12.215]) with mapi id 14.03.0439.000; Thu, 7 Nov 2019 09:58:58 +0800 From: "Ni, Ray" To: "Yao, Jiewen" , "devel@edk2.groups.io" CC: "Wang, Jian J" , "Wu, Hao A" , "Lou, Yun" Subject: Re: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add DeviceSecurity.h Thread-Topic: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add DeviceSecurity.h Thread-Index: AQHVj+cEIaKpMCv2u0qN7YFGo9tarKd9zqVA//+CzwCAAaG0oA== Date: Thu, 7 Nov 2019 01:58:58 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C352902@SHSMSX104.ccr.corp.intel.com> References: <20191031123012.16020-1-jiewen.yao@intel.com> <20191031123012.16020-3-jiewen.yao@intel.com> <734D49CCEBEEF84792F5B80ED585239D5C35174D@SHSMSX104.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503F83EBF9@shsmsx102.ccr.corp.intel.com> In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503F83EBF9@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzI3MjZkYWYtYzgzMy00ZmU2LTlmNjktYTEyMDQ1YzQxYjBkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieGR6Z2xBcUpqbTFFS0NaYlwvdUw3Zjd3aXIyZDBFNURcL1B3XC9YZ21VSWc3cVFQM3FCTDZsVTdWVWNXMDh4UWlubCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: ray.ni@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see. PciIo or UsbIo instance is installed with a different GUID and consu= mer needs to parse the device path to understand what kind of instance (Pci= Io or UsbIo) should be used. > -----Original Message----- > From: Yao, Jiewen > Sent: Wednesday, November 6, 2019 4:25 PM > To: Ni, Ray ; devel@edk2.groups.io > Cc: Wang, Jian J ; Wu, Hao A ;= Lou, Yun > Subject: RE: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add Device= Security.h >=20 > HI > Good comment. Let me answer it in 2 parts. >=20 > 1) The consumer may locate the deice path to know the device type. In thi= s part, you can treat this as redundant > information. >=20 > 2) But we still need a new GUID, because I will install the device access= protocol on this new GUID for the temporary access > for the authentication driver only. >=20 > I don't want to install the device access protocol to the original UEFI s= pec defined GUID to notify everyone that the device > is ready to use, because I have seen some device drivers have callback fu= nction (such as ATA passthru, or NVME passthru) > to start access the device once the device access protocol is installed. >=20 >=20 > Thank you > Yao Jiewen >=20 > > -----Original Message----- > > From: Ni, Ray > > Sent: Wednesday, November 6, 2019 3:56 PM > > To: devel@edk2.groups.io; Yao, Jiewen > > Cc: Wang, Jian J ; Wu, Hao A ; > > Lou, Yun > > Subject: RE: [edk2-devel] [PATCH V2 2/4] MdeModulePkg/Include: Add > > DeviceSecurity.h > > > > > + /// > > > + /// Type of the device. > > > + /// This field is also served as a device Access protocol GUID. > > > + /// The device access protocol is installed on the DeviceHandle. > > > + /// The device access protocol is device specific. > > > + /// EDKII_DEVICE_IDENTIFIER_TYPE_PCI_GUID means the device acces= s > > protocol is PciIo. > > > + /// EDKII_DEVICE_IDENTIFIER_TYPE_USB_GUID means the device acces= s > > protocol is UsbIo. > > > + /// > > > + EFI_GUID DeviceType; > > > > Do we still need DeviceType? Consumer can query the Handle to understan= d the > > device type.