From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.20, mailfrom: michael.a.kubacki@intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by groups.io with SMTP; Thu, 05 Sep 2019 12:54:16 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Sep 2019 12:54:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,471,1559545200"; d="scan'208";a="267127270" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga001.jf.intel.com with ESMTP; 05 Sep 2019 12:54:15 -0700 Received: from orsmsx162.amr.corp.intel.com (10.22.240.85) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 5 Sep 2019 12:54:15 -0700 Received: from orsmsx121.amr.corp.intel.com ([169.254.10.57]) by ORSMSX162.amr.corp.intel.com ([169.254.3.73]) with mapi id 14.03.0439.000; Thu, 5 Sep 2019 12:54:15 -0700 From: "Kubacki, Michael A" To: "devel@edk2.groups.io" Subject: [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction Thread-Topic: [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction Thread-Index: AdVkIxgUrh1RbNqtRiW8SX6BdUiE7g== Date: Thu, 5 Sep 2019 19:54:14 +0000 Message-ID: <49AB4ACB9627B8468F29D589A27B745588AA4398@ORSMSX121.amr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2NiN2MxYjItZjIxMy00M2MxLWE4ZTMtNDc3OGI0ZmZmZDViIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVldaMzJNcFNNbkRESWlOTUhXUks5Vk1uMXFzTitDXC9YT0hIUis3cDNRckppZlhjdGJ0bjVOQkFiRnp5aXpZdFcifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.138] MIME-Version: 1.0 Return-Path: michael.a.kubacki@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I would appreciate any feedback you may have for this proposal. Overview -------------- This is a proposal to reduce SMM usage when using VariableSmmRuntimeDxe wit= h VariableSmm. It will do so by eliminating SMM usage for the vast majority= of runtime service GetVariable ( ) and GetNextVariableName ( ) invocations= . Most UEFI variable usage in typical systems after the variable store is i= nitialized (e.g. manufacturing boots) is due to GetVariable ( ) and GetNext= VariableName ( ) not SetVariable ( ). GetVariable ( ) calls can regularly e= xceed 100 per boot while SetVariable ( ) calls typically remain less than 1= 0 per boot. By focusing on the common case, the majority of overhead associ= ated with SMM can be avoided while still using existing and proven code for= operations such as variable authentication that require an isolated execut= ion environment. * Advantage: Reduces overall system SMM usage * Disadvantage: Requires more Runtime data memory usage Initial Performance Observations ---------------------------------------------- * With these proposed changes, an Intel Atom based SoC saw GetVariable ( )= time for an existing variable reduce from ~220us to ~5us. Major Changes --------------------- 1. Two UEFI variable caches will be maintained. a. "Runtime Cache" - Maintained in VariableSmmRuntimeDxe. Used to serv= e runtime service GetVariable ( ) and GetNextVariableName ( ) callers. b. "SMM cache" - Maintained in VariableSmm to service SMM GetVariable = ( ) and GetNextVariableName ( ) callers. i. A cache in SMRAM retained so SMM modules do not operate on data= outside SMRAM. 2. A new UEFI variable read and write flow will be used as described below= . At any given time, the two caches would be coherent. On a variable write, t= he runtime cache is only updated after validation in SMM and, in the case o= f a non-volatile UEFI variable, the variable must also be successfully writ= ten to non-volatile storage.=20 Primary Concern ----------------------- The primary item that I believe warrants feedback is whether there are subs= tantial concerns with keeping a variable store cache that is used to serve = UEFI Runtime Services callers in a buffer of EfiRuntimeServicesData type.=20 Proof-of-Concept Implementation ---------------------------------------------- The implementation is available in the following commit - check the commit = message for some more details.=20 https://github.com/makubacki/edk2/commit/d812d43412a26e44581d283382596a863c= 1ae825 Please note this is "POC" level code quality and there will be cleanup of l= ock interfaces used and some other minor changes. Please feel free to leave= any comments on the changes. This code was tested with the master branch o= f edk2 on an Intel Whiskey Lake U reference validation platform. Why Keep SMM on Variable Writes ------------------------------------------------ * SMM provides a fairly ubiquitous isolated execution environment in x86 f= or authenticated UEFI variables. * BIOS region SPI flash write restrictions to SMM in platforms today can b= e retained. Today's UEFI Variable Cache -------------------------------------- * Maintained in SMRAM via VariableSmm. * A "write-through" cache of variable data in the form of a UEFI variable = store. * Non-volatile and volatile variables are maintained in separate buffers (= variable stores). Runtime & SMM Cache Coherency ---------------------------------------------- The non-volatile cache should always accurately reflect non-volatile storag= e contents (done today) and the "SMM cache" and "Runtime cache" should alwa= ys be coherent on access. The runtime cache is updated by VariableSmm. Updating both caches from within a SMM SetVariable ( ) operation is fairly = straightforward but a race condition can occur if an SMI occurs during the = execution of runtime code reading from the runtime cache. To handle this ca= se, a runtime cache read lock is introduced that explicitly moves pending u= pdates from SMM to the runtime cache if an SMM update occurs while the runt= ime cache is locked. Note that is not expected a Runtime services call will= interrupt SMM processing since all cores rendezvous in SMM.=20 New Key Elements for Coherence --------------------------------------------- Runtime DXE (VariableSmmRuntimeDxe) 1. RuntimeCacheReadLock - A global lock used to lock read access to the ru= ntime cache. 2. RuntimeCachePendingUpdate - A global flag used to notify runtime code o= f a pending cache update in SMM. SMM (VariableSmm) 1. FlushRuntimeCachePendingUpdate SMI - A SW SMI handler that synchronizes= the runtime cache buffer with the SMM cache buffer. Proposed Runtime DXE Read Flow ---------------------------------------------- 1. Wait for RuntimeCacheReadLock to be free 2. Acquire RuntimeCacheReadLock 3. If RuntimeCachePendingUpdate flag is set then: 3.a. Trigger FlushRuntimeCachePendingUpdate SMI 3.b. Verify RuntimeCachePendingUpdate flag is cleared 4. Perform read from RuntimeCache 5. Release RuntimeCacheReadLock Proposed FlushRuntimeCachePendingUpdate SMI ------------------------------------------------------------------- 1. If RuntimeCachePendingUpdate flag is not set: 1.a. Return 2. Copy the data at RuntimeCachePendingOffset of RuntimeCachePendingLength= to RuntimeCache 3. Clear the RuntimeCachePendingUpdate flag Proposed SMM Write Flow ------------------------------------- 1. Perform variable authentication and non-volatile write. If either fail,= return an error to the caller. 2. If RuntimeCacheReadLock is set then: 2.a. Set RuntimeCachePendingUpdate flag 2.b. Update RuntimeCachePendingOffset and RuntimeCachePendingLength to= cover the a superset of the pending chunk (for simplicity, the entire vari= able store is currently synchronized). 3. Else: 3.a. Update RuntimeCache 4. Update SmmCache - Note: RT read cannot occur during SMI processing since all cores are= locked in SMM.