Patent Description:
Today, update of an SMM driver requires a platform reset. This platform reset is very expensive for a fleet of hundreds of thousands of server nodes in a Data Center/Cloud environment. Such resets cause non-monetizable downtime and inability to maintain SLAs (Service Level Agreements) for Cloud Service Providers (CSPs).

<CIT> describes a method for updating the management information of a computer system. According to the method, a system management information table is built during the execution of the computer system. The system management information table is built from a base set of management information and one or more updates to the base set of management information. The updates to the base set of management information may be stored a protected region of a non-volatile memory device. A utility program is provided for storing the updates to the management information in the non-volatile memory device.

<CIT> describes a method of updating secure pre-boot firmware in a computing system in real-time, including: storing in a secure firmware memory region a firmware update module configured to update the secure pre-boot firmware; responsive to a user request to update the secure pre-boot firmware: entering a processor management mode, including suspending operating system and user-level data processing operations; executing the firmware update module; and determining whether the secure pre-boot firmware was successfully updated; and exiting the processor management mode, including resuming operating system and user-level data processing operations and notifying the user of the successful update.

<CIT> describes an information handling system for enhanced system management mode (SMM) security including a processor, system management random access memory (SMRAM), persistent memory, and basic input/output (BIOS) memory. The system includes instructions that, when loaded and executed by the processor, cause the processor to initialize the memory, initialize the BIOS memory, initialize the persistent memory, and check whether the system has previously executed a power-on self test (POST) routine. Based on a determination that the system has not previously executed a POST routine, the processor unzips the SMM Code located in the BIOS memory and stores the unzipped SMM Code in the persistent memory and in the SMRAM. Based on a determination that the system has previously executed a POST routine, the processor creates a duplicate copy of the SMM Code from the persistent memory and stores the duplicate copy in the SMRAM.

<CIT> describes a method for making PEI phase implementation independent from DXE phase implementation in a computer system implementing the Extensible Firmware Interface standard.

The dependent claims recite selected optional features.

The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified:.

Embodiments of methods and apparatus for seamless SMM global driver update base on SMM Root-of-Trust are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention.

For clarity, individual components in the Figures herein may also be referred to by their labels in the Figures, rather than by a particular reference number. Additionally, reference numbers referring to a particular type of component (as opposed to a particular component) may be shown with a reference number followed by "(typ)" meaning "typical. " It will be understood that the configuration of these components will be typical of similar components that may exist but are not shown in the drawing Figures for simplicity and clarity or otherwise similar components that are not labeled with separate reference numbers. Conversely, "(typ)" is not to be construed as meaning the component, element, etc. is typically used for its disclosed function, implement, purpose, etc..

In accordance with aspects of embodiments disclosed herein, mechanisms are provided to load and replace SMM drivers at runtime in a secure manner, without requiring SMM firmware update and platform reset.

SMM code is executed by BIOS (Basic Input Output System) during boot in a hidden area of memory called SMRAM (System Management Random Access Memory) space. Certain register lock, MSR setting and feature enabling/disabling will require SMM privilege and is executable only when the processor is switched into SMM mode. Seamless Update of SMM Global Driver Update provides a method to load and replace all SMM drivers (include SMM infrastructure) on an already shipped platform production for purposes such as bug fixes.

To support SMM Driver Update, this disclosure proposes the following:.

A System Management Interrupt (SMI) is generated by platform events such as RAS, power management, thermal events or via software-triggered SMIs. An SMI is a high priority, non-maskable, broadcast interrupt. On receipt of an SMI the processors in the system save their context and transition to a mode called System Management Mode.

In SMM, the processor has saved the context it came out of. The handler code then sets up its own environment (page tables, Interrupt Descriptor Tables (IDTs) etc.) and executes code that is placed by the platform BIOS/Firmware in an area of SMRAM (System Management RAM).

SMRAM is an area of memory that is hidden from the OS. Any writes to this area from outside of SMM will get dropped and reads from outside of SMM will results in -<NUM>'s getting returned. This area of memory is only visible to processors that have switched to SMM.

SMM mode is predominantly used for handling runtime events that requires an intimate silicon and platform knowledge to handle, in an OS transparent fashion, such as RAS events, which are highly platform and silicon specific or can't trust ring-<NUM> code to handle.

System Resource Defense de-privileges all the SMI handlers and SMM rendezvous to Ring3, defines a set of policy on which system resource (IO, MSR, Register Context, etc.) can be accessed by SMI handlers, and provides a ring0 SMM policy shim (SPS) to enforce the policy. The policy is set and locked by the BIOS POST code.

As discussed above, embodiments disclosed herein implement a mechanism to securely replace all SMM drivers and restore the runtime context, without platform reset using a small Root-of-Trust in SMM (SmmRoT). The SmmRoT is the Root-of-Trust for Update (RTU), and is a standalone module that is independent of any SMM services. It is responsible for unload existing SMM drivers, loading and executing new SMM drivers (including SMM infrastructure and other SMM components), and restoring the runtime context. The SmmRoT itself is protected and not updatable, in one embodiment.

The embodiments define a new architecture SMM boot mode called SMM_BOOT_MODE_RUNTIME_UPDATE for SMM driver running in the runtime update. The normal boot is SMM boot mode SMM_BOOT_MODE_INIT.

The SmmRoT maintains a preserved area in SMRAM. This area is reserved by BIOS during boot and will be preserved during runtime update. The content of the preserved area includes the temporary (temp) stack, temp page table, temp GDT/IDT, temp exception handler, temp AP handler during the update. It also includes the context saved by other SMM drivers for restoration after the update.

One embodiment of an SMRAM memory layout is shown in <FIG>. SMM <NUM> includes an SmmRot (RUT) <NUM>, an SmmCore <NUM>, a heap <NUM>, an SmmDriverX <NUM>, an SmmCPU <NUM>, a heap <NUM>, an SmmDriverY <NUM>, a heap <NUM>, a context buffer <NUM>, an SMBase <NUM>, a SaveState <NUM> and an entrypoint <NUM>. SmmCPU includes an SMM Entrypoint <NUM>, and exception hander <NUM>, and an AP handler <NUM>. Heap <NUM> includes a stack <NUM>, a page table <NUM>, and a Global Descriptor Table (GDT)/IDT <NUM>.

The new components for context buffer <NUM> include a temp stack <NUM>, a temp page table <NUM>, a temp GDT/IDT <NUM>, a temp exception handler <NUM>, and a temp AP handler <NUM>. SmmRoT <NUM>, SMBase <NUM> and SaveState <NUM> are components that are not updatable during runtime. Context buffer <NUM> is located in the preserved temp area. The remaining components are runtime updatable.

In one embodiment, the boot flow of system BIOS is:.

One embodiment of the boot flow is illustrated in flowchart <NUM> of <FIG>. In a block <NUM> the SMM Initial Program Loader (SmmIpl) allocates the SMRAM region and loads SmmRoT. In a block <NUM> the SmmIpl allocates a reserved SMRAM region for runtime driver reload to be used for the preserved area by SmmRoT. SmmIpl then passes the control to the SmmRoT in a block <NUM> by invoking SmmRoT.

Next, in a block <NUM> the SmmRoT sets SMM boot mode to SMM_BOOT_MODE_INIT in a block <NUM>, then allocates SMRAM region and loads SmmCore in a block <NUM>. The SmmRot then invokes the SmmCore in a block <NUM> to pass control to the SmmCore and other SMM drivers.

In a block <NUM>, the SmmCore initiates the SMM policy shim and performs other SMM initialization in a block <NUM>. The SMM driver registers resource access policy to the SMM policy shim in a block <NUM>. The SmmCore then invokes an SmmRoT callback in a block <NUM>, passing control back to the SmmRoT.

In a block <NUM>, the SmmRoT produces a runtime update context save/restore service and registers a Ring0 SMI handler for Runtime SMM Driver update in a block <NUM>. BIOS then continues the boot flow process.

In one embodiment, the runtime SMM Global Driver Update includes:.

<FIG> shows a flowchart <NUM> illustrating the runtime driver update process, according to one embodiment. As shown at left, the process begins with and OS agent sending a UEFI capsule <NUM> including a firmware volume with new SMM core and other SMM drivers <NUM> and Auth data <NUM> through the BIOS-OS interface (not shown) to a driver update SMI handler running in Ring0 at SMI entry point <NUM>. In a block <NUM> UEFI capsule <NUM> is authenticated (validated) as described above. In a block <NUM>, the SMM Driver Update SMI handler invokes other SMM driver's callback function to notify the runtime driver update. In one embodiment, SYS Exit to Ring0 before invoking each SMM driver's callback function.

The processing next proceeds to other SMM drivers running in Ring3. In block <NUM> and <NUM> each SMM driver's callback stops its service, saves the runtime context with the SMM runtime update context save/restore service. The processing is returned to the driver update SMI hander in a return block <NUM>.

After all other SMM drivers are suspended, in a block <NUM> the SMM Driver Update SMI handler cleans up SMRAM, only leaves itself, save state and context buffer untouched. In one embodiment, to run the code, the RTU must setup the temporary page table temporary GDT/IDT, temporary stack, temporary exception handler and temporary AP handler in the preserved content buffer, as depicted in a block <NUM> In one embodiment, the SMI handler cleans up the SMM Policy Shim to unlock all resource access.

In a block <NUM>, The SMI handler sets the SMM Boot Mode to RUNTIME_UPDATE. It then loads the new SmmCore from the capsule image, lets it re-initialize the environment and dispatch all SMM Drivers in in the capsule image in a block <NUM>. When the SMM driver is dispatched, it checks the SMM Boot Mode, and skip unnecessary initialization steps in RUNTIME_UPDATE mode. When SMM CPU driver is dispatched, it produces a service to exit SMM in RUNTIME_UPDATE boot mode.

The process then returns to other SMM drivers at driver entry <NUM>. After all new SMM drivers are dispatched, the SMI handler invokes other SMM driver's callback function to notify the context restore, as shown in a block <NUM>. In one embodiment, SYS Exit to Ring0 before invoking each SMM driver's callback function, as depicted by a return block <NUM>, a block <NUM>, and a restore callback block <NUM>.

In a block <NUM>, each SMM driver's callback restores its context from the SMM runtime update context save/restore service. In one embodiment, following a return block <NUM>, each SMM driver register its new resource access policy to SMM Policy Shim in a block <NUM>. After all new SMM drivers are restored, the SMM Global Driver Update is completed. The SMI Handler exits SMM with the exit SMM service produced by SMM CPU driver, with operations resuming in RSM block <NUM>.

<FIG> depicts a compute node <NUM> in which aspects of the embodiments disclosed above may be implemented. Compute node <NUM> includes one or more processors <NUM>, which provides processing, operation management, and execution of instructions for compute node <NUM>. Processor <NUM> can include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, multi-core processor or other processing hardware to provide processing for compute node <NUM>, or a combination of processors. Processor <NUM> controls the overall operation of compute node <NUM>, and can be or include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices.

In one example, compute node <NUM> includes interface <NUM> coupled to processor <NUM>, which can represent a higher speed interface or a high throughput interface for system components that needs higher bandwidth connections, such as memory subsystem <NUM> or optional graphics interface components <NUM>, or optional accelerators <NUM>. Interface <NUM> represents an interface circuit, which can be a standalone component or integrated onto a processor die. Where present, graphics interface <NUM> interfaces to graphics components for providing a visual display to a user of compute node <NUM>. In one example, graphics interface <NUM> can drive a high definition (HD) display that provides an output to a user. High definition can refer to a display having a pixel density of approximately <NUM> PPI (pixels per inch) or greater and can include formats such as full HD (e.g., 1080p), retina displays, <NUM> (ultra-high definition or UHD), or others. In one example, the display can include a touchscreen display. In one example, graphics interface <NUM> generates a display based on data stored in memory <NUM> or based on operations executed by processor <NUM> or both. In one example, graphics interface <NUM> generates a display based on data stored in memory <NUM> or based on operations executed by processor <NUM> or both.

In some embodiments, accelerators <NUM> can be a fixed function offload engine that can be accessed or used by a processor <NUM>. For example, an accelerator among accelerators <NUM> can provide data compression capability, cryptography services such as public key encryption (PKE), cipher, hash/authentication capabilities, decryption, or other capabilities or services. In some embodiments, in addition or alternatively, an accelerator among accelerators <NUM> provides field select controller capabilities as described herein. In some cases, accelerators <NUM> can be integrated into a CPU socket (e.g., a connector to a motherboard or circuit board that includes a CPU and provides an electrical interface with the CPU). For example, accelerators <NUM> can include a single or multi-core processor, graphics processing unit, logical execution unit single or multi-level cache, functional units usable to independently execute programs or threads, application specific integrated circuits (ASICs), neural network processors (NNPs), programmable control logic, and programmable processing elements such as field programmable gate arrays (FPGAs). Accelerators <NUM> can provide multiple neural networks, CPUs, processor cores, general purpose graphics processing units, or graphics processing units can be made available for use by AI or ML models. For example, the AI model can use or include any or a combination of: a reinforcement learning scheme, Q-learning scheme, deep-Q learning, or Asynchronous Advantage Actor-Critic (A3C), combinatorial neural network, recurrent combinatorial neural network, or other AI or ML model. Multiple neural networks, processor cores, or graphics processing units can be made available for use by AI or ML models.

Memory subsystem <NUM> represents the main memory of compute node <NUM> and provides storage for code to be executed by processor <NUM>, or data values to be used in executing a routine. Memory subsystem <NUM> can include one or more memory devices <NUM> such as readonly memory (ROM), flash memory, one or more varieties of random access memory (RAM) such as DRAM, or other memory devices, or a combination of such devices. Memory <NUM> stores and hosts, among other things, operating system (OS) <NUM> to provide a software platform for execution of instructions in compute node <NUM>. Additionally, applications <NUM> can execute on the software platform of OS <NUM> from memory <NUM>. Applications <NUM> represent programs that have their own operational logic to perform execution of one or more functions. Processes <NUM> represent agents or routines that provide auxiliary functions to OS <NUM> or one or more applications <NUM> or a combination. OS <NUM>, applications <NUM>, and processes <NUM> provide software logic to provide functions for compute node <NUM>. In one example, memory subsystem <NUM> includes memory controller <NUM>, which is a memory controller to generate and issue commands to memory <NUM>. It will be understood that memory controller <NUM> could be a physical part of processor <NUM> or a physical part of interface <NUM>. For example, memory controller <NUM> can be an integrated memory controller, integrated onto a circuit with processor <NUM>.

While not specifically illustrated, it will be understood that compute node <NUM> can include one or more buses or bus systems between devices, such as a memory bus, a graphics bus, interface buses, or others. Buses or other signal lines can communicatively or electrically couple components together, or both communicatively and electrically couple the components. Buses can include physical communication lines, point-to-point connections, bridges, adapters, controllers, or other circuitry or a combination. Buses can include, for example, one or more of a system bus, a Peripheral Component Interconnect (PCI) bus, a Hyper Transport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or an Institute of Electrical and Electronics Engineers (IEEE) standard <NUM> bus (Firewire).

In one example, compute node <NUM> includes interface <NUM>, which can be coupled to interface <NUM>. In one example, interface <NUM> represents an interface circuit, which can include standalone components and integrated circuitry. In one example, multiple user interface components or peripheral components, or both, couple to interface <NUM>. Network interface <NUM> provides compute node <NUM> the ability to communicate with remote devices (e.g., servers or other computing devices) over one or more networks. Network interface <NUM> can include an Ethernet adapter, wireless interconnection components, cellular network interconnection components, USB (universal serial bus), or other wired or wireless standards-based or proprietary interfaces. Network interface <NUM> can transmit data to a device that is in the same data center or rack or a remote device, which can include sending data stored in memory. Network interface <NUM> can receive data from a remote device, which can include storing received data into memory. Various embodiments can be used in connection with network interface <NUM>, processor <NUM>, and memory subsystem <NUM>.

In one example, compute node <NUM> includes one or more IO interface(s) <NUM>. IO interface <NUM> can include one or more interface components through which a user interacts with compute node <NUM> (e.g., audio, alphanumeric, tactile/touch, or other interfacing). Peripheral interface <NUM> can include any hardware interface not specifically mentioned above. Peripherals refer generally to devices that connect dependently to compute node <NUM>. A dependent connection is one where compute node <NUM> provides the software platform or hardware platform or both on which operation executes, and with which a user interacts.

In one example, compute node <NUM> includes storage subsystem <NUM> to store data in a nonvolatile manner. In one example, in certain system implementations, at least certain components of storage <NUM> can overlap with components of memory subsystem <NUM>. Storage subsystem <NUM> includes storage device(s) <NUM>, which can be or include any conventional medium for storing large amounts of data in a nonvolatile manner, such as one or more magnetic, solid state, or optical based disks, or a combination. Storage <NUM> holds code or instructions and data <NUM> in a persistent state (i.e., the value is retained despite interruption of power to compute node <NUM>). Storage <NUM> can be generically considered to be a "memory," although memory <NUM> is typically the executing or operating memory to provide instructions to processor <NUM>. Whereas storage <NUM> is nonvolatile, memory <NUM> can include volatile memory (i.e., the value or state of the data is indeterminate if power is interrupted to compute node <NUM>). In one example, storage subsystem <NUM> includes controller <NUM> to interface with storage <NUM>. In one example controller <NUM> is a physical part of interface <NUM> or processor <NUM> or can include circuits or logic in both processor <NUM> and interface <NUM>.

A volatile memory is memory whose state (and therefore the data stored in it) is indeterminate if power is interrupted to the device. Dynamic volatile memory requires refreshing the data stored in the device to maintain state. One example of dynamic volatile memory includes DRAM, or some variant such as Synchronous DRAM (SDRAM). A memory subsystem as described herein may be compatible with a number of memory technologies, such as DDR3 (Double Data Rate version <NUM>, original release by JEDEC (Joint Electronic Device Engineering Council) on June <NUM>, <NUM>). DDR4 (DDR version <NUM>, initial specification published in September <NUM> by JEDEC), DDR4E (DDR version <NUM>), LPDDR3 (Low Power DDR version3, JESD209-3B, August <NUM> by JEDEC), LPDDR4) LPDDR version <NUM>, JESD209-<NUM>, originally published by JEDEC in August <NUM>), WIO2 (Wide Input/output version <NUM>, JESD229-<NUM> originally published by JEDEC in August <NUM>), HBM (High Bandwidth Memory, JESD325, originally published by JEDEC in October <NUM>, LPDDR5 (currently in discussion by JEDEC), HBM2 (HBM version <NUM>), currently in discussion by JEDEC, or others or combinations of memory technologies, and technologies based on derivatives or extensions of such specifications. The JEDEC standards are available at www.

A non-volatile memory (NVM) device is a memory whose state is determinate even if power is interrupted to the device. In one embodiment, the NVM device can comprise a block addressable memory device, such as NAND technologies, or more specifically, multi-threshold level NAND flash memory (for example, Single-Level Cell ("SLC"), Multi-Level Cell ("MLC"), Quad-Level Cell ("QLC"), Tri-Level Cell ("TLC"), or some other NAND). A NVM device can also comprise a byte-addressable write-in-place three dimensional cross point memory device, or other byte addressable write-in-place NVM device (also referred to as persistent memory), such as single or multi-level Phase Change Memory (PCM) or phase change memory with a switch (PCMS), NVM devices that use chalcogenide phase change material (for example, chalcogenide glass), resistive memory including metal oxide base, oxygen vacancy base and Conductive Bridge Random Access Memory (CB-RAM), nanowire memory, ferroelectric random access memory (FeRAM, FRAM), magneto resistive random access memory (MRAM) that incorporates memristor technology, spin transfer torque (STT)-MRAM, a spintronic magnetic junction memory based device, a magnetic tunneling junction (MTJ) based device, a DW (Domain Wall) and SOT (Spin Orbit Transfer) based device, a thyristor based memory device, or a combination of any of the above, or other memory.

A power source (not depicted) provides power to the components of compute node <NUM>. More specifically, power source typically interfaces to one or multiple power supplies in compute node <NUM> to provide power to the components of compute node <NUM>. In one example, the power supply includes an AC to DC (alternating current to direct current) adapter to plug into a wall outlet. Such AC power can be renewable energy (e.g., solar power) power source. In one example, power source includes a DC power source, such as an external AC to DC converter. In one example, power source or power supply includes wireless charging hardware to charge via proximity to a charging field. In one example, power source can include an internal battery, alternating current supply, motion-based power supply, solar power supply, or fuel cell source.

In an example, compute node <NUM> can be implemented using interconnected compute sleds of processors, memories, storages, network interfaces, and other components. High speed interconnects can be used such as: Ethernet (IEEE <NUM>), remote direct memory access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), quick UDP Internet Connections (QUIC), RDMA over Converged Ethernet (RoCE), Peripheral Component Interconnect express (PCIe), Intel® QuickPath Interconnect (QPI), Intel® Ultra Path Interconnect (UPI), Intel® On-Chip System Fabric (IOSF), Omnipath, Compute Express Link (CXL), HyperTransport, high-speed fabric, NVLink, Advanced Microcontroller Bus Architecture (AMBA) interconnect, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (<NUM>), 3GPP <NUM>, and variations thereof. Data can be copied or stored to virtualized storage nodes using a protocol such as NVMe over Fabrics (NVMe-oF) or NVMe.

In the foregoing embodiments implementations are described and illustrated as applied to an SMM and SMM driver update use case. However, this is merely exemplary and non-limiting. More generally, the principles and teachings disclosed herein may be used to perform runtime updates of secure execution mode firmware components, including secure execution mode infrastructure components. As used herein, including the claims, secure execution mode is an execution mode of the processor during which execution of an operating system is paused and provides access to firmware code and hardware that is otherwise not accessible outside of the secure execution mode.

In addition to applying secure execution mode firmware for computing platforms with CPUs, the teaching and principles disclosed herein may be applied to Other Processing Units (collectively termed XPUs) including one or more of Graphic Processor Units (GPUs) or General Purpose GPUs (GP-GPUs), Tensor Processing Unit (TPU) Data Processor Units (DPUs), Artificial Intelligence (AI) processors or AI inference units and/or other accelerators, FPGAs and/or other programmable logic (used for compute purposes), etc. While some of the diagrams herein show the use of CPUs, this is merely exemplary and non-limiting. Generally, any type of XPU may be used in place of a CPU in the illustrated embodiments. Moreover, as used in the following claims, the term "processor" is used to generically cover CPUs and various forms of XPUs.

Although some embodiments have been described in reference to particular implementations, other implementations are possible according to some embodiments. Additionally, the arrangement and/or order of elements or other features illustrated in the drawings and/or described herein need not be arranged in the particular way illustrated and described. Many other arrangements are possible according to some embodiments.

In each system shown in a figure, the elements in some cases may each have a same reference number or a different reference number to suggest that the elements represented could be different and/or similar. However, an element may be flexible enough to have different implementations and work with some or all of the systems shown or described herein. The various elements shown in the figures may be the same or different. Which one is referred to as a first element and which is called a second element is arbitrary.

In the description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. Rather, in particular embodiments, "connected" may be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. Additionally, "communicatively coupled" means that two or more elements that may or may not be in direct contact with each other, are enabled to communicate with each other. For example, if component A is connected to component B, which in turn is connected to component C, component A may be communicatively coupled to component C using component B as an intermediary component.

An embodiment is an implementation or example of the inventions. Reference in the specification to "an embodiment," "one embodiment," "some embodiments," or "other embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least some embodiments, but not necessarily all embodiments, of the inventions. The various appearances "an embodiment," "one embodiment," or "some embodiments" are not necessarily all referring to the same embodiments.

Not all components, features, structures, characteristics, etc. described and illustrated herein need be included in a particular embodiment or embodiments. If the specification states a component, feature, structure, or characteristic "may", "might", "can" or "could" be included, for example, that particular component, feature, structure, or characteristic is not required to be included. If the specification or claim refers to "a" or "an" element, that does not mean there is only one of the element.

As discussed above, various aspects of the embodiments herein may be facilitated by corresponding software and/or firmware components and applications, such as software and/or firmware executed by an embedded processor or the like. Thus, embodiments of this invention may be used as or to support a software program, software modules, firmware, and/or distributed software executed upon some form of processor, processing core or embedded logic a virtual machine running on a processor or core or otherwise implemented or realized upon or within a non-transitory computer-readable or machine-readable storage medium. A non-transitory computer-readable or machine-readable storage medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a non-transitory computer-readable or machine-readable storage medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a computer or computing machine (e.g., computing device, electronic system, etc.), such as recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.). The content may be directly executable ("object" or "executable" form), source code, or difference code ("delta" or "patch" code). A non-transitory computer-readable or machine-readable storage medium may also include a storage or database from which content can be downloaded. The non-transitory computer-readable or machine-readable storage medium may also include a device or product having content stored thereon at a time of sale or delivery. Thus, delivering a device with stored content, or offering content for download over a communication medium may be understood as providing an article of manufacture comprising a non-transitory computer-readable or machine-readable storage medium with such content described herein.

Various components referred to above as processes, servers, or tools described herein may be a means for performing the functions described. The operations and functions performed by various components described herein may be implemented by software running on a processing element, via embedded hardware or the like, or any combination of hardware and software. Such components may be implemented as software modules, hardware modules, special-purpose hardware (e.g., application specific hardware, ASICs, DSPs, etc.), embedded controllers, hardwired circuitry, hardware logic, etc. Software content (e.g., data, instructions, configuration information, etc.) may be provided via an article of manufacture including non-transitory computer-readable or machine-readable storage medium, which provides content that represents instructions that can be executed. The content may result in a computer performing various functions/operations described herein.

As used herein, a list of items joined by the term "at least one of" can mean any combination of the listed terms. For example, the phrase "at least one of A, B or C" can mean A; B; C; A and B; A and C; B and C; or A, B and C.

Claim 1:
A method for updating secure execution mode code in system firmware of a computing platform including a processor, wherein the secure execution mode comprises a System Management Mode, SMM, the method comprising:
during an execution mode of the processor comprising an operating system runtime mode under which an operating system is executed on the processor,
receiving an update package including one or more updated secure execution mode components, wherein the updated secure execution mode components include one or more updated SMM drivers;
switching the execution mode of the processor to a secure execution mode;
while in the secure execution mode;
storing a system runtime context;
unloading one or more existing secure execution mode components;
loading and executing the one or more updated secure execution mode components;
restoring the system runtime context;
exiting the secure execution mode; and
returning the execution mode to the operating system runtime mode,
wherein the updated secure execution mode components include secure execution mode infrastructure code.