From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by mx.groups.io with SMTP id smtpd.web11.333.1687998228629953029 for ; Wed, 28 Jun 2023 17:23:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=VhX2pdDu; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: quicinc.com, ip: 205.220.168.131, mailfrom: quic_aiyengar@quicinc.com) Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35T0JgWG023165; Thu, 29 Jun 2023 00:23:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=qcppdkim1; bh=Ot46+THt8Alo4QgeNknH7Rgt2OuLCazoHoNaZljzZO4=; b=VhX2pdDu3Jf94e+WicUy3qrkyKMwjV7VINUHKvbyAV8OWuOz/uFpfSW+Tf7mqYUGPHrD ZN8lXCCkRH+pJJFNn1XLKUSR4nOvtHBOMdh23VUU94Gpe+DdXGWd3zpAjUsgFXfUpjcK OsJwVPWdHK4pc3qXsdFUsY9tkfS/SpHMsOK7yF/uGBuBTxnQSdrsy9FBcN5E+YxlQ9j1 rjDb9icRLoU0ER0zCqr3zgpPW8yAS1Z3mlNDZyR/1hV2xplaWrv4MDpy+I5x0h/+oDrF J0tjYTGauRlz6XejdPaLlyiWw32ms/Bqu5MNaamzbOXtkqJPCbPxDtxhUCHtk9818nVh +A== Received: from nasanppmta01.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3rgy1tg0vb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2023 00:23:44 +0000 Received: from nasanex01a.na.qualcomm.com (nasanex01a.na.qualcomm.com [10.52.223.231]) by NASANPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 35T0Nhen007398 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2023 00:23:43 GMT Received: from nasanex01a.na.qualcomm.com (10.52.223.231) by nasanex01a.na.qualcomm.com (10.52.223.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42; Wed, 28 Jun 2023 17:23:42 -0700 Received: from nasanex01a.na.qualcomm.com ([fe80::c691:3b9c:e565:6f69]) by nasanex01a.na.qualcomm.com ([fe80::c691:3b9c:e565:6f69%12]) with mapi id 15.02.0986.042; Wed, 28 Jun 2023 17:23:42 -0700 From: "Ajay Iyengar (QUIC)" To: "'devel@edk2.groups.io'" , 'Andrew Fish' , "Leif Lindholm (QUIC)" , 'Michael D Kinney' CC: 'Ruiyu Ni' , 'Star Zeng' , "'michael.a.rothman@intel.com'" , "'felixp@ami.com'" Subject: Managing boot order dependencies with ResetNotification Protocol Thread-Topic: Managing boot order dependencies with ResetNotification Protocol Thread-Index: AdmqH8tQYJ73ApyMSdymhO9MCRMNWg== Date: Thu, 29 Jun 2023 00:23:42 +0000 Message-ID: <7795152053a34b42ac9ffa2327eed287@quicinc.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.93.107] MIME-Version: 1.0 X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: z1R0AFG0zAQjzIeCfaYVWFtaDuHsomCd X-Proofpoint-GUID: z1R0AFG0zAQjzIeCfaYVWFtaDuHsomCd X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-06-28_14,2023-06-27_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 impostorscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1011 adultscore=0 priorityscore=1501 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306290001 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7795152053a34b42ac9ffa2327eed287quicinccom_" --_000_7795152053a34b42ac9ffa2327eed287quicinccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, This is a comment and query on the Reset Notification Protocol defined by t= he UEFI specification. The specification requires clients to be notified for ResetSystem() without= imposing any specific ordering on how these notifications are dispatched: = https://uefi.org/specs/UEFI/2.10/39_Micellaneous_Protocols.html#reset-notif= ication-protocol. For example, this is used for gracefully shutting off NVMe and TPM through = their respective spec defined power off notifications: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Pci/NvmExpre= ssDxe/NvmExpressHci.c#L950 https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Dxe/Tcg2D= xe.c#L2597 If we assume a platform implementing fTPM using NVMe-RPMB, the boot order = would require NVMe as a dependency for TPM, but that might result in an iss= ue with the reset notification path. The default EDK2 implementation dispat= ches these notifications in boot order: https://github.com/tianocore/edk2/b= lob/master/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c#L78. = Here NVMe would power off, before TPM commits to NVMe-RPMB within its rese= t notification callback. Reversing the order of dispatch (i.e. reverse-boot= order) would help with this situation. We have several similar situations on our platform -- drivers with a Depex = ordering registering for ResetNotify which would benefit from being signale= d in reverse-boot order. Are there any provisions that could be made with r= egards to ensuring the ordering requirement? Could we mimic the behavior o= f the ExitBootServices event dispatch for ResetNotify: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Event/E= vent.c#L492 ? [The proposal would be to use InsertHeadList() instead of InsertTailList() = in RegisterResetNotify()] Thanks, Ajay --_000_7795152053a34b42ac9ffa2327eed287quicinccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

This is a comment and query on the Reset Notification Protocol define= d by the UEFI specification.

 

The specification requires clients to be notified for ResetSystem() w= ithout imposing any specific ordering on how these notifications are dispat= ched: https= ://uefi.org/specs/UEFI/2.10/39_Micellaneous_Protocols.html#reset-notificati= on-protocol. 

For example, this is used for gracefully shutting off NVMe and TPM th= rough their respective spec defined power off notifications: 

https://github.com/tianocore/edk2/blob/= master/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c#L950

https://github.com/tianocore/edk2/blob/master/SecurityP= kg/Tcg/Tcg2Dxe/Tcg2Dxe.c#L2597

 

If we assume a platform implementing fTPM using NVMe-RPMB,  the = boot order would require NVMe as a dependency for TPM, but that might resul= t in an issue with the reset notification path. The default EDK2 implementation dispatches these notifications in boot ord= er: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Univer= sal/ResetSystemRuntimeDxe/ResetSystem.c#L78.  Here NVMe would power off, before TPM commits to NVMe-RPMB within it= s reset notification callback. Reversing the order of dispatch (i.e. revers= e-boot order) would help with this situation.

 

We have several similar situations on our platfo= rm -- drivers with a Depex ordering registering for ResetNotify which would= benefit from being signaled in reverse-boot order. Are there any provisions that could be= made with regards to ensuring the ordering requirement?  Could we mimic the behavior of the ExitBootServices= event dispatch for ResetNotify:

https://github.com/tianocore/edk2/blob/master/MdeModul= ePkg/Core/Dxe/Event/Event.c#L492 ?

[The proposal would be to use InsertHeadList() instead of InsertTailList() in RegisterRese= tNotify()]=

 

Thanks,

Ajay

--_000_7795152053a34b42ac9ffa2327eed287quicinccom_--