US20200192659A1 - Modular microcode (ucode) patch method to support runtime persistent update - Google Patents
Modular microcode (ucode) patch method to support runtime persistent update Download PDFInfo
- Publication number
- US20200192659A1 US20200192659A1 US16/801,382 US202016801382A US2020192659A1 US 20200192659 A1 US20200192659 A1 US 20200192659A1 US 202016801382 A US202016801382 A US 202016801382A US 2020192659 A1 US2020192659 A1 US 2020192659A1
- Authority
- US
- United States
- Prior art keywords
- ucode
- image
- version
- extension
- patch
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 39
- 230000002085 persistent effect Effects 0.000 title abstract description 15
- 239000002775 capsule Substances 0.000 claims description 33
- 238000013461 design Methods 0.000 claims description 2
- 230000004044 response Effects 0.000 claims 1
- 230000008569 process Effects 0.000 description 18
- 238000010586 diagram Methods 0.000 description 12
- 238000013459 approach Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000005538 encapsulation Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 239000013598 vector Substances 0.000 description 2
- 230000001427 coherent effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/656—Updates while running
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/22—Microcontrol or microprogram arrangements
- G06F9/24—Loading of the microprogram
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
Definitions
- Cloud-hosted services and applications are generally implemented in large data centers housing thousands of compute platforms such as servers, blade servers, server modules, micro-servers, etc. Oftentimes, the platforms are configured as virtualized execution used for hosting virtual machines and “containers” or the like in which software applications are run.
- Each platform includes physical hardware, firmware (also referred to as BIOS—Basic Input-Output System), and software.
- BIOS Basic Input-Output System
- the root of trust for the platform is the platform hardware and firmware, which although less susceptible to malicious actors that software still may pose a risk. For security and other reasons (e.g., performance), platform firmware may need to be updated.
- BIOS in personal computer (PC) platforms was a monolithic block of code that was installed in Read-Only Memory (ROM), wherein BIOS was updated by replacing the BIOS ROM chip. Subsequently, the BIOS was installed in EEPROM (Electrically Erasable Programmable Read-Only Memory) and could be replaced (in its entirely) via a firmware update.
- Intel® Corporation began development of a modular firmware architecture known as the Extensible Firmware Interface (EFI).
- EFI Extensible Firmware Interface
- Unified EFI forum was formed as an industry-wide organization to promote adoption and continue the development of the EFI Specification. Using the EFI 1.10 Specification as the starting point, this industry group released began releasing firmware specifications, renamed Unified EFI (UEFI).
- UEFI firmware dominates today's platform architectures.
- UEFI firmware has a modular architecture that includes a core block to which modules are added, wherein the core block is booted first and the booted code is used to load the modules during platform boot.
- EEPROMs most of today's firmware is stored in flash memory (sometimes referred to as BIOS flash and referred to as persistent flash memory).
- BIOS flash sometimes referred to as BIOS flash and referred to as persistent flash memory.
- platform firmware may be stored in a non-volatile storage device, which includes but is not limited to flash memory and EEPROMs.
- bootloaders may be used to load platform firmware.
- bootloaders are used for mobile devices and some server platforms.
- FIG. 1 shows a diagram 100 depicting cloud customers' process to upgrade uCode patch, including a runtime method and persistent patch update into BIOS flash.
- the process start with a CPU (central processing unit, also referred to as a processor) vendor issuing a uCode release 102 , which may be provided to an end user (or otherwise made available to an end user) and/or may be provided or made available to an OEM/ODM (original equipment manufacturer/original design manufacturer, such as a platform vendor)
- uCode update plan 104 if uCode release 102 is a uCode runtime patch, it can be immediately applied using an operating system (OS) kernel tool without system reset, as depicted in a push uCode patch for runtime update block 106 .
- OS operating system
- uCode update plan 104 entails requesting the OEM/ODM for a new BIOS package.
- the OEM/ODM will prepare a new Bios package with new uCode 108 and provide it to the end user.
- the end user will push the new BIOS package to a BIOS upgrade queue.
- a scheduled system reset is used to complete installation of the uCode BIOS patch.
- BIOS persistent patch processes may result in cloud providers not meeting service level agreement (SLA) metrics, further providing financial incentives to delay scheduling of BIOS updates.
- SLA service level agreement
- malicious actors continue to develop ever-more advanced attacks, including development of attack vectors that may reach the platform BIOS level.
- FIG. 1 is a schematic diagram illustrating a conventional BIOS update process
- FIG. 2 is a schematic diagram illustrating a high-level view of a modular uCode patch method to support runtime persistent update, according to one embodiment
- FIG. 3 is a diagram illustrating the structure of a BIOS flash layout, according to one embodiment
- FIGS. 3 a -3 e illustrate states of the BIOS flash layout corresponding to different timeframes in connection handling multiple uCode patches, wherein FIG. 3 a illustrates the state of the BIOS flash layout at a first timeframe, FIG. 3 b illustrates the state of the BIOS flash layout at a second timeframe, FIG. 3 c illustrates the state of the BIOS flash layout at a third timeframe, FIG. 3 d illustrates the state of the BIOS flash layout at a fourth timeframe, and FIG. 3 e illustrates the state of the BIOS flash layout at a fifth timeframe;
- FIG. 4 is a diagram of a uCode capsule package, according to one embodiment
- FIG. 5 is a diagram illustrating an embodiment of an encapsulation process that produces different uCode capsule package formats including formats with and without authentication information comprising signed certifications;
- FIG. 6 is a flowchart illustrating logic and operations for implementing a ping-pong scheme under which uCode images are written to first and second uCode extension regions in an alternating manner, according to one embodiment
- FIG. 7 is a flowchart illustrating logic and operations implemented by a firmware boot service to selective boot a most recent uCode image, according to one embodiment.
- FIG. 8 is a schematic diagram of an exemplary compute platform on which embodiments disclosed herein may be implemented.
- Embodiments of a modular microcode (uCode) patch method to support runtime persistent update and associated apparatus are described herein.
- numerous specific details are set forth to provide a thorough understanding of embodiments of the invention.
- One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc.
- well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
- a novel runtime update method to apply uCode patch into BIOS flash persistently while applying a runtime OS uCode patch into a platform or system is provided.
- This approach eliminates requirements on additional BIOS package release and system reset for persistent uCode update into BIOS flash, which help relieve the burden on cloud customers when applying uCode updates.
- FIG. 2 A diagram 200 illustrating a high-level view of an embodiment of the approach is shown in FIG. 2 .
- the process begins with the CPU vendor issuing a uCode release 202 that is provided to end users (e.g., cloud customers) and/or platform vendors or is otherwise made available to the end users and platform vendors (e.g., via download).
- the end user employs a uCode update plan 204 that will push the uCode patch for runtime update, as depicted by a block 208 .
- the platform vendor uses uCode release 202 to create a uCode update package 206 , which is provided to the end user.
- uCode update package 206 will then be used to update a uCode flash region at runtime, as depicted by a block 210 .
- the runtime update of the OS uCode patch and persistent uCode patch take effect together.
- the uCode patch (or patches, as explained below) include uCode that cannot be implemented during runtime.
- the OEM/ODM creates the uCode update package and provides it to the end user.
- uCode release 202 may be provided to the cloud operator, and the cloud operator will prepare the uCode update package (not shown).
- FIG. 3 shows a diagram 300 illustrating the structure of a BIOS flash layout, according to one embodiment.
- the BIOS region mapped to an address of 4G minus 16 MB is divided into three FVs (firmware volumes), as depicted by a Boot FV 302 , a uCode Extension FV 304 that may be stored in one or more slots in a uCode extension region #1) and a uCode Extension FV 306 that may be stored in one or more slots in a uCode extension region #2.
- FVs firmware volumes
- Boot FV 302 contains a reset vector to (the starting address for) Firmware Interface Table (FIT) pointers 308 , a BIOS startup module entry 310 , a FIT startup ACM entry 314 , a uCode path Entry 314 , a FIT header 316 , and a uCode base image 318 (that corresponds to the latest bootable uCode image).
- FIT pointer 308 is fixed and is not permitted to be changed via a runtime update.
- uCode extension region #1 and uCode extension region #2 are uCode extension regions used to store the runtime uCode patches (also referred to as FVs or uCode images).
- FIT pointer 308 comprises an entry table with pointers (entry points) to various regions in the BIOS flash layout.
- pointers entity points
- the location and size of uCode regions in BIOS flash are fixed, and thus the entry table for FIT pointer 308 will not be updated while updating contents of uCode regions.
- uCode extension regions #1 and #2 are empty, the starting address for uCode extension region #1 is located at 0xFFFF_FFFF.
- all uCode extension regions e.g., uCode extension regions #1 and #2 in the embodiments illustrated herein
- the uCode patch is encapsulated into a capsule format and a capsule firmware update interface is used to update the uCode regions in BIOS flash.
- the capsule format uCode image can be built by either an offline phase or online phase to support flexible integrity check method. Examples of capsule formats and packaging schemes are shown in FIGS. 4 and 5 .
- the capsule formats comply with the capsule format defined by an appliable UEFI specification.
- a uCode capsule package 400 includes a UEFI capsule header 402 , a firmware management protocol (FPM) field 404 , an authentication information (AuthInfo) field 406 , and a payload 408 containing a uCode firmware volume 410 .
- the uCode patch is encapsulated into standard capsule format (e.g., uCode capsule package 400 ) by some system utility to ensure the uCode capsule package for the same CPU SKU (stocking unit—i.e., the same CPU part) is compliant across different platform vendors' BIOS implementations.
- An SMI (System Management Interrupt) hander is defined in BIOS to parse the uCode patch from the capsule image.
- the uCode capsule package 400 can be dynamically generated either by offline tools from the OEM/ODM/platform vendor or by online tools from the cloud customer configured to support flexible release and variable security check requirements.
- a signature may be added into AuthInfo field 406 ; this signature is created using platform credentials from either the OEM/ODM/platform vendor or from cloud customers.
- the SMI handler is configured to check the integrity of the BIOS update image by validating this signature with an internal platform credential.
- a given uCode release will including multiple uCode patches that are configured to be implemented on the same CPU model while supporting different stepping levels.
- stepping levels for a CPU may including A0, A1, A2, etc.
- the stepping levels may use a next letter, such as B0, then B1, B2, etc.
- the uCode patches for a CPU model for a given stepping level may differ from uCode patches for that CPU model for another stepping level, thus multiple uCode patches may be included in an update package.
- an OEM/ODM may create an uCode update package with multiple uCode patches to support multiple stepping levels for a CPU model or produce (e.g., blade server, server module, etc. for which the uCode update package is targeted.
- a platform vendor may manufacture and sell a given blade server for several years employing the same CPU model, while during that time the stepping versions of the CPU model will have changed.
- a uCode update for the blade server may require multiple patches.
- uCode update packages may be more targeted to only be implemented on a CPU model with a specific stepping level.
- the uCode update package may only include a single uCode patch.
- the cloud operator may generate uCode update packages with multiple uCode patches.
- the encapsulation process starts with one or more uCode patches 500 that are encapsulated into a uCode capsule format 502 including a uCode firmware volume 504 .
- a platform signature from an OEM or ODM is needed, a uCode capsule format 506 signed with an OEM/ODM certificate is generated, including an AuthInfo field 508 (containing the certificate) and uCode firmware volume 504 .
- a signature from a cloud customer is needed, a uCode capsule format 510 signed with a cloud customer certificate is generated, including an AuthInfo field 512 (containing the certificate) and uCode firmware volume 504 .
- uCode capsule package 502 can be provided as is.
- a “ping-pong” scheme is used to alternatively update uCode extension FVs to support roll-back to the most recent uCode patch in case some failures/exceptions crash the uCode extension FV being updated.
- the ping-pong scheme is used to alternatively update two uCode extension FVs, e.g., uCode Extension FV #1 and uCode Extension FV #2 in FIG. 3 and uCode images in uCode extension regions #1 and #2 in FIGS. 3 a -3 e presented below. If the uCode extension FV being updated is crashed due to some exceptions, such as an unexpected system shutdown or hang, the system is able to roll back to the most recent uCode patch from the alternative uCode extension FV.
- uCode base region 318 in Boot FV 302 is defined as one backup region to store the uCode base image; this region supports sync-up to latest bootable uCode image in a subsequent (next) boot.
- FIG. 6 shows a flowchart 600 illustrating logic and operations for implementing the ping-pong scheme, according to one embodiment.
- the process begins in a block 602 in which the uCode capsule has been successfully parsed.
- a decision block 604 a determination is made to whether the uCode image is valid. If the uCode image is determined to be invalid, the answer to decision block 604 is NO, and the logic proceeds to an error handler 608 . If the uCode image is determined to be valid, the answer to decision block 604 is YES, resulting in the logic proceeding to a block 606 in which the variable for the pointer (e.g., the base address of uCode extension region #1 or #2) of the next update uCode region is read. In one embodiment this pointer value is stored in uCode patch entry 314 .
- the variable for the pointer e.g., the base address of uCode extension region #1 or #2
- the logic then proceeds to a block 616 in which the variable for the pointer of the next update region is updated to reflect which uCode extension region will be used next (e.g., swapped to point to the uCode extension region that wasn't used).
- each firmware image will include a version number, such as depicted by a version number 320 for uCode base region 318 .
- each of uCode extension region #1 and uCode extension region #2 are empty, except for headers 322 and 324 with values of xFFFF, which in one embodiment is used to indicate the firmware volume in the uCode extension region is invalid or corrupt.
- uCode patch entry 314 will initially include pointers to both uCode extension region #1 and uCode extension region #2, and during boot both uCode extension region #1 and uCode extension region #2 will be inspected to see if they are storing a valid firmware volume.
- FIG. 3 b illustrates a second timeframe T2 during which a uCode capsule package 326 comprising a first uCode update package has been received including a first set of uCode patches depicted as uCode patches 327 A 0 and 327 B 0 .
- the uCode patches are written to uCode extension region #1 as a uCode image (also referred to as a firmware volume).
- this uCode image has a version number of x0002 (included in a header 328 ), indicating it is a newer version than the current firmware volume (uCode image) stored in uCode base region 320 .
- uCode patch entry 314 now is depicted as including a firmware volume pointer 330 that points to the starting address for uCode extension region #1 (and thus points to uCode FV version x0002), and a next patch pointer 332 that points to the starting address for uCode extension region #2, which will be used to store the next uCode patch.
- FIG. 3 c illustrates a third timeframe T3 during which a second set of uCode patches (depicted as uCode patches 333 A 0 and 333 B 0 ) encapsulated in a uCode capsule package 334 has been received and has been successfully written to uCode extension region #2 as uCode firmware volume version x0003 (as indicated in a header 336 ).
- Version number x0003 is a newer FV version than both the current FV stored in uCode base region 320 and uCode FV version x0002.
- FV pointer 330 of uCode patch entry 314 now points to the starting address for uCode extension region #2 (and thus points to uCode FV version x0003), while next patch pointer 332 points to the starting address for uCode extension region #1, which will be used to store the next uCode image extracted from the next uCode update package.
- the latest firmware image (e.g., FV with the highest version number) is copied into the uCode base region as part of a base region sync-up processes. Operations and logic for implementing this process, according to one embodiment, are shown in a flowchart 700 of FIG. 7 .
- uCode patch entry 314 includes a pointer to a valid FV in uCode extension region #1 and #2.
- uCode patch entry 314 employs permanent pointers to slots in each of uCode extension region #1 and #2, and thus both uCode extension regions are checked for a valid FV.
- uCode patch entry 314 includes FV pointer 330 that points to a valid FV (which will be stored in either uCode extension region #1or #2). If neither uCode extension region #1 nor #2 stores a valid FV, the logic proceeds to a block 710 in which the FV in uCode base region 318 is booted.
- a valid FV is found in block 704 , that uCode image corresponding to the FV will be loaded and booted (if successfully loaded) in a block 708 .
- a decision block 710 a determination is made to whether the uCode image in uCode base region 318 is older than the loaded uCode image. If not, the answer is NO and the logic proceeds to block 706 in which the loaded uCode image is skipped and the uCode image in uCode base region 318 is loaded and booted.
- the answer to decision block 710 is YES, and the logic proceeds to a block 712 in which the loaded image from uCode extension region #1 or #2 (as applicable) is synced-up to uCode base region 318 by copying the uCode image into uCode base region 318 . This results in updating the uCode image in uCode base region 318 to the most recent version.
- the firmware comprises a combination of core UEFI components and extensions implemented as UEFI modules that are also referred to as images, such as UEFI driver images and UEFI application images.
- a uCode patch may be targeted to a particular UEFI module, and thus only uCode for that particular UEFI module is updated/replaced during the sync-up process rather than updating/replacing the entirety of the uCode in the uCode base region.
- FIG. 3 d An example of this sync-up process is illustrated in FIG. 3 d , which corresponds to a timeframe T4.
- a uCode image with version x0003 is loaded from uCode extension region #2, and after confirmation that it has successfully booted, the uCode image is written to uCode base region 318 .
- FV pointer 332 is set to 0XFFFF (or some other predefined value) to indicate that there are no newer uCode images in either uCode extension region #1 or #2.
- next patch pointer 332 still points to uCode extension region #1.
- the SMI BIOS code may be configured to filter for only those uCode patches that have a stepping version that matches the stepping version of the processor.
- providers of uCode update packages can build and send out update package with multiple stepping versions without having to know the particular stepping version that is implemented by each processor for which uCode is to be updated.
- FIG. 3 e The state of the BIOS flash layout after a fifth timeframe T5 is shown in FIG. 3 e .
- a third uCode capsule package 338 is received that includes a uCode FV having a version x0004 and including uCode patches 339 A 0 and 339 B 0 .
- This uCode image is written to uCode extension region #1, which corresponded with the uCode extension region pointed to by next patch pointer 332 following timeframe T4 in FIG. 3 d .
- the value for next patch pointer 332 is swapped to now point to uCode extension region #2, which will be the uCode extension region to be used for the next uCode patch.
- FIGS. 8 shows an embodiment of a platform architecture 800 corresponding to a computing platform suitable for implementing aspects of the embodiments described herein.
- Architecture 800 includes a hardware layer in the lower portion of the diagram including platform hardware 802 , and a software layer that includes software components running in host memory 804 .
- Architecture 800 implements the modular microcode (uCode) patch method to support runtime persistent update, as illustrated by the BIOS flash layout depicted for BIOS flash device 824 corresponding to the BIOS flash layout of diagram 300 in FIG. 3 .
- uCode modular microcode
- Platform hardware 802 includes a processor 806 having a System on a Chip (SoC) architecture including a central processing unit (CPU) 808 with M processor cores 810 , each coupled to a Level 1 and Level 2 (L1/L2) cache 812 .
- SoC System on a Chip
- CPU central processing unit
- L1/L2 cache 812 Level 1 and Level 2 cache 812 .
- Each of the processor cores and L1/L2 caches are connected to an interconnect 814 to which each of a memory interface 816 and a Last Level Cache (LLC) 818 is coupled, forming a coherent memory domain.
- Memory interface is used to access host memory 804 in which various software components are loaded and run via execution of associated software instructions on processor cores 810 .
- Processor 806 further includes an Input/Output (I/O) interconnect hierarchy, which includes one or more levels of interconnect circuitry and interfaces that are collectively depicted as I/O interconnect & interfaces 820 for simplicity.
- I/O interconnect & interfaces 820 Various components and peripheral devices are coupled to processor 806 via respective interfaces (not all separately shown), including a network interface 822 , a BIOS flash device 824 in which BIOS uCode is stored having a BIOS flash layout illustrated in diagram 300 and discussed above.
- BIOS flash device 824 may be operatively coupled to processor 806 via a platform controller hub (PCH) 831 .
- Platform hardware 802 also includes a disk drive or solid state disk (SSD) with controller 826 in which software components 828 are stored.
- SSD disk drive or solid state disk
- controller 826 in which software components 828 are stored.
- all or a portion of the software components used to implement the software aspects of embodiments herein may be loaded over a network 829 accessed
- a current or new uCode image and various UEFI modules are loaded into host memory 804 and booted, followed loading and initialization of various software components.
- the software components include a host operating system 830 and a Type-2 hypervisor 831 used to host n virtual machines (VMs) VM 1, VM 2 . . . VM n, each including an operating system 432 on which one or more applications 434 are run.
- VMs virtual machines
- Platform architectures employing containers, such as Docker®-type containers, may be implemented in a similar manner.
- non-virtualized computing platforms that only run a single instance of an operating system may also be used.
- the uCode runtime patch update approach implemented by the embodiments disclosed herein provides several advantages.
- Third, encapsulating the uCode patch(es) into a capsule format ensures the uCode capsule image is complaint across different vendors platforms for same the CPU SKU, including support for different stepping versions. This also provide the flexibility and simplicity for cloud customer to adopt different security options.
- 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.
- 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.
- 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.
- 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.
- embodiments of this invention may be used as or to support a software program, software modules, and/or firmware (BIOS), 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.
- BIOS firmware
- 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).
- 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.
- 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.
- a list of items joined by the term “at least one of” can mean any combination of the listed terms.
- 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.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Stored Programmes (AREA)
Abstract
Description
- The use of cloud-hosted services and applications has exploded in the past decade and continues to grow at an exponential rate. Cloud-hosted services and applications are generally implemented in large data centers housing thousands of compute platforms such as servers, blade servers, server modules, micro-servers, etc. Oftentimes, the platforms are configured as virtualized execution used for hosting virtual machines and “containers” or the like in which software applications are run.
- Each platform includes physical hardware, firmware (also referred to as BIOS—Basic Input-Output System), and software. The root of trust for the platform is the platform hardware and firmware, which although less susceptible to malicious actors that software still may pose a risk. For security and other reasons (e.g., performance), platform firmware may need to be updated.
- Historically, the BIOS in personal computer (PC) platforms was a monolithic block of code that was installed in Read-Only Memory (ROM), wherein BIOS was updated by replacing the BIOS ROM chip. Subsequently, the BIOS was installed in EEPROM (Electrically Erasable Programmable Read-Only Memory) and could be replaced (in its entirely) via a firmware update. In approximately 1998, Intel® Corporation began development of a modular firmware architecture known as the Extensible Firmware Interface (EFI). In 2005, the Unified EFI forum was formed as an industry-wide organization to promote adoption and continue the development of the EFI Specification. Using the EFI 1.10 Specification as the starting point, this industry group released began releasing firmware specifications, renamed Unified EFI (UEFI). UEFI firmware dominates today's platform architectures. UEFI firmware has a modular architecture that includes a core block to which modules are added, wherein the core block is booted first and the booted code is used to load the modules during platform boot. Also, rather than EEPROMs, most of today's firmware is stored in flash memory (sometimes referred to as BIOS flash and referred to as persistent flash memory). More generally, platform firmware may be stored in a non-volatile storage device, which includes but is not limited to flash memory and EEPROMs.
- Under some platform architectures, bootloaders may be used to load platform firmware. For example, bootloaders are used for mobile devices and some server platforms.
-
FIG. 1 shows a diagram 100 depicting cloud customers' process to upgrade uCode patch, including a runtime method and persistent patch update into BIOS flash. The process start with a CPU (central processing unit, also referred to as a processor) vendor issuing auCode release 102, which may be provided to an end user (or otherwise made available to an end user) and/or may be provided or made available to an OEM/ODM (original equipment manufacturer/original design manufacturer, such as a platform vendor) According to an uCodeupdate plan 104, if uCoderelease 102 is a uCode runtime patch, it can be immediately applied using an operating system (OS) kernel tool without system reset, as depicted in a push uCode patch forruntime update block 106. However, if uCoderelease 102 needs a BIOS release (e.g., a persistent patch process that needs to update the uCode in boot time through a BIOS update package that requires a system reset to apply the update into persistent flash memory), uCodeupdate plan 104 entails requesting the OEM/ODM for a new BIOS package. The OEM/ODM will prepare a new Bios package with new uCode 108 and provide it to the end user. As depicted in a block 110, the end user will push the new BIOS package to a BIOS upgrade queue. At some subsequent point in time, which could take days, weeks, months, or longer), a scheduled system reset is used to complete installation of the uCode BIOS patch. - For cloud scenarios (e.g., cloud-hosted services and applications), the persistent patch process is problematic and poses risks from operation perspective:
- The cloud customer (i.e., end user) needs to ask platform vendors to build the new BIOS package with the required uCode;
- The cloud customer has to put the new BIOS package into a BIOS upgrade queue and wait for the time to schedule the system reset to update the patch into BIOS flash;
- The cloud scenario is very resistant to the system reset request because the system reset needs service migration and impact service uptime, and the result is a lot of BIOS release packages are pending in the upgrade queue without update in a timely manner;
- This results in a long and risky process for cloud operation. Failure to apply the right uCode patch during a next system reboot causes problems on security, performance and reliability.
- Downtime required for implementing such BIOS persistent patch processes may result in cloud providers not meeting service level agreement (SLA) metrics, further providing financial incentives to delay scheduling of BIOS updates. At the same time, malicious actors continue to develop ever-more advanced attacks, including development of attack vectors that may reach the platform BIOS level.
- 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:
-
FIG. 1 is a schematic diagram illustrating a conventional BIOS update process; -
FIG. 2 is a schematic diagram illustrating a high-level view of a modular uCode patch method to support runtime persistent update, according to one embodiment; -
FIG. 3 is a diagram illustrating the structure of a BIOS flash layout, according to one embodiment; -
FIGS. 3a-3e illustrate states of the BIOS flash layout corresponding to different timeframes in connection handling multiple uCode patches, whereinFIG. 3a illustrates the state of the BIOS flash layout at a first timeframe,FIG. 3b illustrates the state of the BIOS flash layout at a second timeframe,FIG. 3c illustrates the state of the BIOS flash layout at a third timeframe,FIG. 3d illustrates the state of the BIOS flash layout at a fourth timeframe, andFIG. 3e illustrates the state of the BIOS flash layout at a fifth timeframe; -
FIG. 4 is a diagram of a uCode capsule package, according to one embodiment; -
FIG. 5 is a diagram illustrating an embodiment of an encapsulation process that produces different uCode capsule package formats including formats with and without authentication information comprising signed certifications; -
FIG. 6 is a flowchart illustrating logic and operations for implementing a ping-pong scheme under which uCode images are written to first and second uCode extension regions in an alternating manner, according to one embodiment; -
FIG. 7 is a flowchart illustrating logic and operations implemented by a firmware boot service to selective boot a most recent uCode image, according to one embodiment; and -
FIG. 8 is a schematic diagram of an exemplary compute platform on which embodiments disclosed herein may be implemented. - Embodiments of a modular microcode (uCode) patch method to support runtime persistent update and associated apparatus are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
- Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
- 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 the embodiments disclosed herein, a novel runtime update method to apply uCode patch into BIOS flash persistently while applying a runtime OS uCode patch into a platform or system is provided. This approach eliminates requirements on additional BIOS package release and system reset for persistent uCode update into BIOS flash, which help relieve the burden on cloud customers when applying uCode updates.
- A diagram 200 illustrating a high-level view of an embodiment of the approach is shown in
FIG. 2 . As before, the process begins with the CPU vendor issuing a uCoderelease 202 that is provided to end users (e.g., cloud customers) and/or platform vendors or is otherwise made available to the end users and platform vendors (e.g., via download). If the uCode patch employ late-binding firmware that is able to be implemented by an operating system during runtime using kernel tool or the like, the end user employs auCode update plan 204 that will push the uCode patch for runtime update, as depicted by ablock 208. In parallel, the platform vendor usesuCode release 202 to create auCode update package 206, which is provided to the end user.uCode update package 206 will then be used to update a uCode flash region at runtime, as depicted by ablock 210. As a result, the runtime update of the OS uCode patch and persistent uCode patch take effect together. - In other instances, the uCode patch (or patches, as explained below) include uCode that cannot be implemented during runtime. In this case, the OEM/ODM creates the uCode update package and provides it to the end user. In the case of a cloud operator,
uCode release 202 may be provided to the cloud operator, and the cloud operator will prepare the uCode update package (not shown). -
FIG. 3 shows a diagram 300 illustrating the structure of a BIOS flash layout, according to one embodiment. In one implementation, the BIOS region mapped to an address of 4G minus 16 MB is divided into three FVs (firmware volumes), as depicted by aBoot FV 302, auCode Extension FV 304 that may be stored in one or more slots in a uCode extension region #1) and auCode Extension FV 306 that may be stored in one or more slots in a uCodeextension region # 2.Boot FV 302 contains a reset vector to (the starting address for) Firmware Interface Table (FIT)pointers 308, a BIOSstartup module entry 310, a FITstartup ACM entry 314, auCode path Entry 314, aFIT header 316, and a uCode base image 318 (that corresponds to the latest bootable uCode image). InBIOS FV 302,FIT pointer 308 is fixed and is not permitted to be changed via a runtime update. uCodeextension region # 1 and uCodeextension region # 2 are uCode extension regions used to store the runtime uCode patches (also referred to as FVs or uCode images). -
FIT pointer 308 comprises an entry table with pointers (entry points) to various regions in the BIOS flash layout. In one embodiment, the location and size of uCode regions in BIOS flash are fixed, and thus the entry table forFIT pointer 308 will not be updated while updating contents of uCode regions. - In one embodiment, if uCode
extension regions # 1 and #2 are empty, the starting address for uCodeextension region # 1 is located at 0xFFFF_FFFF. In one embodiment, all uCode extension regions (e.g., uCodeextension regions # 1 and #2 in the embodiments illustrated herein) support modular update by the host operation system at runtime and the boot firmware service at boot time. During a subsequent boot, if the uCode update entries are valid, they will be utilized to load the uCode with a higher version number, as described and illustrated below. - In some embodiments, the uCode patch is encapsulated into a capsule format and a capsule firmware update interface is used to update the uCode regions in BIOS flash. The capsule format uCode image can be built by either an offline phase or online phase to support flexible integrity check method. Examples of capsule formats and packaging schemes are shown in
FIGS. 4 and 5 . In one embodiment, the capsule formats comply with the capsule format defined by an appliable UEFI specification. - As illustrated in
FIG. 4 , auCode capsule package 400 includes aUEFI capsule header 402, a firmware management protocol (FPM)field 404, an authentication information (AuthInfo)field 406, and apayload 408 containing auCode firmware volume 410. In one embodiment, the uCode patch is encapsulated into standard capsule format (e.g., uCode capsule package 400) by some system utility to ensure the uCode capsule package for the same CPU SKU (stocking unit—i.e., the same CPU part) is compliant across different platform vendors' BIOS implementations. - An SMI (System Management Interrupt) hander is defined in BIOS to parse the uCode patch from the capsule image. Generally, the
uCode capsule package 400 can be dynamically generated either by offline tools from the OEM/ODM/platform vendor or by online tools from the cloud customer configured to support flexible release and variable security check requirements. To support the integrity check for the update image, a signature may be added intoAuthInfo field 406; this signature is created using platform credentials from either the OEM/ODM/platform vendor or from cloud customers. For such cases (employing signatures), in one embodiment the SMI handler is configured to check the integrity of the BIOS update image by validating this signature with an internal platform credential. - In some instances, a given uCode release will including multiple uCode patches that are configured to be implemented on the same CPU model while supporting different stepping levels. For example, stepping levels for a CPU may including A0, A1, A2, etc. In the cases where changes are more significant, the stepping levels may use a next letter, such as B0, then B1, B2, etc. The uCode patches for a CPU model for a given stepping level may differ from uCode patches for that CPU model for another stepping level, thus multiple uCode patches may be included in an update package.
- Generally, an OEM/ODM may create an uCode update package with multiple uCode patches to support multiple stepping levels for a CPU model or produce (e.g., blade server, server module, etc. for which the uCode update package is targeted. For example, a platform vendor may manufacture and sell a given blade server for several years employing the same CPU model, while during that time the stepping versions of the CPU model will have changed. Thus, a uCode update for the blade server may require multiple patches.
- In the case of a cloud operator, uCode update packages may be more targeted to only be implemented on a CPU model with a specific stepping level. In this case, the uCode update package may only include a single uCode patch. In other cases, the cloud operator may generate uCode update packages with multiple uCode patches.
- As shown in
FIG. 5 , the encapsulation process starts with one or moreuCode patches 500 that are encapsulated into auCode capsule format 502 including auCode firmware volume 504. If a platform signature from an OEM or ODM is needed, auCode capsule format 506 signed with an OEM/ODM certificate is generated, including an AuthInfo field 508 (containing the certificate) anduCode firmware volume 504. If a signature from a cloud customer is needed, auCode capsule format 510 signed with a cloud customer certificate is generated, including an AuthInfo field 512 (containing the certificate) anduCode firmware volume 504. If no platform signature is needed,uCode capsule package 502 can be provided as is. - In one embodiment, a “ping-pong” scheme is used to alternatively update uCode extension FVs to support roll-back to the most recent uCode patch in case some failures/exceptions crash the uCode extension FV being updated. The ping-pong scheme is used to alternatively update two uCode extension FVs, e.g., uCode
Extension FV # 1 and uCodeExtension FV # 2 inFIG. 3 and uCode images in uCodeextension regions # 1 and #2 inFIGS. 3a-3e presented below. If the uCode extension FV being updated is crashed due to some exceptions, such as an unexpected system shutdown or hang, the system is able to roll back to the most recent uCode patch from the alternative uCode extension FV. Under one embodiment,uCode base region 318 inBoot FV 302 is defined as one backup region to store the uCode base image; this region supports sync-up to latest bootable uCode image in a subsequent (next) boot. -
FIG. 6 shows aflowchart 600 illustrating logic and operations for implementing the ping-pong scheme, according to one embodiment. The process begins in ablock 602 in which the uCode capsule has been successfully parsed. In a decision block 604 a determination is made to whether the uCode image is valid. If the uCode image is determined to be invalid, the answer to decision block 604 is NO, and the logic proceeds to anerror handler 608. If the uCode image is determined to be valid, the answer to decision block 604 is YES, resulting in the logic proceeding to a block 606 in which the variable for the pointer (e.g., the base address of uCodeextension region # 1 or #2) of the next update uCode region is read. In one embodiment this pointer value is stored inuCode patch entry 314. - In a decision block 610 a determination is made to whether uCode
extension region # 1 or uCodeextension region # 2 is to be used to store the uCode patch image. In one embodiment this determination is made based on the pointer value inuCode patch entry 314. If the pointer value inuCode patch entry 314 points to uCodeextension region # 1, the logic flows to the left-hand branch where the uCode image is written to uCodeextension region # 1, as depicted in ablock 612. If the pointer value inuCode patch entry 314 points to uCodeextension region # 2, the logic flows to the right-hand branch where the uCode image is written to uCodeextension region # 2, as depicted in ablock 614. For both branches, the logic then proceeds to ablock 616 in which the variable for the pointer of the next update region is updated to reflect which uCode extension region will be used next (e.g., swapped to point to the uCode extension region that wasn't used). - An initial configuration of the BIOS flash layout prior to receiving any uCode patches and corresponding to a first timeframe T1 is shown in
FIG. 3a . In one embodiment, each firmware image will include a version number, such as depicted by aversion number 320 foruCode base region 318. In this initial configuration, each of uCodeextension region # 1 and uCodeextension region # 2 are empty, except forheaders uCode patch entry 314 will initially include pointers to both uCodeextension region # 1 and uCodeextension region # 2, and during boot both uCodeextension region # 1 and uCodeextension region # 2 will be inspected to see if they are storing a valid firmware volume. -
FIG. 3b illustrates a second timeframe T2 during which auCode capsule package 326 comprising a first uCode update package has been received including a first set of uCode patches depicted as uCode patches 327A0 and 327B0. The uCode patches are written to uCodeextension region # 1 as a uCode image (also referred to as a firmware volume). As further shown, this uCode image has a version number of x0002 (included in a header 328), indicating it is a newer version than the current firmware volume (uCode image) stored inuCode base region 320.uCode patch entry 314 now is depicted as including afirmware volume pointer 330 that points to the starting address for uCode extension region #1 (and thus points to uCode FV version x0002), and anext patch pointer 332 that points to the starting address for uCodeextension region # 2, which will be used to store the next uCode patch. -
FIG. 3c illustrates a third timeframe T3 during which a second set of uCode patches (depicted as uCode patches 333A0 and 333B0) encapsulated in auCode capsule package 334 has been received and has been successfully written to uCodeextension region # 2 as uCode firmware volume version x0003 (as indicated in a header 336). Version number x0003 is a newer FV version than both the current FV stored inuCode base region 320 and uCode FV version x0002.FV pointer 330 ofuCode patch entry 314 now points to the starting address for uCode extension region #2 (and thus points to uCode FV version x0003), whilenext patch pointer 332 points to the starting address for uCodeextension region # 1, which will be used to store the next uCode image extracted from the next uCode update package. - In accordance with another aspect of the uCode patch update scheme, during a next BIOS boot process, the latest firmware image (e.g., FV with the highest version number) is copied into the uCode base region as part of a base region sync-up processes. Operations and logic for implementing this process, according to one embodiment, are shown in a
flowchart 700 ofFIG. 7 . - The process begins in a
block 702 in which the firmware boot service boots into the system. In ablock 704 the firmware boot service identifies whetheruCode patch entry 314 includes a pointer to a valid FV in uCodeextension region # 1 and #2. In one embodiment,uCode patch entry 314 employs permanent pointers to slots in each of uCodeextension region # 1 and #2, and thus both uCode extension regions are checked for a valid FV. In another embodiment, such as illustrated inFIGS. 3b and 3c ,uCode patch entry 314 includesFV pointer 330 that points to a valid FV (which will be stored in either uCode extension region #1or #2). If neither uCodeextension region # 1 nor #2 stores a valid FV, the logic proceeds to ablock 710 in which the FV inuCode base region 318 is booted. - If a valid FV is found in
block 704, that uCode image corresponding to the FV will be loaded and booted (if successfully loaded) in ablock 708. In a decision block 710 a determination is made to whether the uCode image inuCode base region 318 is older than the loaded uCode image. If not, the answer is NO and the logic proceeds to block 706 in which the loaded uCode image is skipped and the uCode image inuCode base region 318 is loaded and booted. If the loaded uCode image is newer than theuCode base region 318 image, the answer to decision block 710 is YES, and the logic proceeds to ablock 712 in which the loaded image from uCodeextension region # 1 or #2 (as applicable) is synced-up touCode base region 318 by copying the uCode image intouCode base region 318. This results in updating the uCode image inuCode base region 318 to the most recent version. - It is noted that during a sync-up process either a portion of the uCode in
uCode base region 318 is updated/replaced, or all the uCode is updated/replaced, depending on the configuration and contents of the update package. For example, under a modular firmware architecture, such as UEFI, the firmware (BIOS uCode) comprises a combination of core UEFI components and extensions implemented as UEFI modules that are also referred to as images, such as UEFI driver images and UEFI application images. In some instances, a uCode patch may be targeted to a particular UEFI module, and thus only uCode for that particular UEFI module is updated/replaced during the sync-up process rather than updating/replacing the entirety of the uCode in the uCode base region. - An example of this sync-up process is illustrated in
FIG. 3d , which corresponds to a timeframe T4. In this instance, a uCode image with version x0003 is loaded from uCodeextension region # 2, and after confirmation that it has successfully booted, the uCode image is written touCode base region 318. This results in the most recent uCode image being stored inuCode base region 318. As a result, in the illustratedembodiment FV pointer 332 is set to 0XFFFF (or some other predefined value) to indicate that there are no newer uCode images in either uCodeextension region # 1 or #2. As further shown,next patch pointer 332 still points to uCodeextension region # 1. - In some embodiments under which multiple stepping version uCode patches are included in an update package, the SMI BIOS code may be configured to filter for only those uCode patches that have a stepping version that matches the stepping version of the processor. Under this approach, providers of uCode update packages can build and send out update package with multiple stepping versions without having to know the particular stepping version that is implemented by each processor for which uCode is to be updated.
- The state of the BIOS flash layout after a fifth timeframe T5 is shown in
FIG. 3e . During this timeframe, a thirduCode capsule package 338 is received that includes a uCode FV having a version x0004 and including uCode patches 339A0 and 339B0. This uCode image is written to uCodeextension region # 1, which corresponded with the uCode extension region pointed to bynext patch pointer 332 following timeframe T4 inFIG. 3d . Following the ping-pong scheme, the value fornext patch pointer 332 is swapped to now point to uCodeextension region # 2, which will be the uCode extension region to be used for the next uCode patch. -
FIGS. 8 shows an embodiment of aplatform architecture 800 corresponding to a computing platform suitable for implementing aspects of the embodiments described herein.Architecture 800 includes a hardware layer in the lower portion of the diagram includingplatform hardware 802, and a software layer that includes software components running inhost memory 804.Architecture 800 implements the modular microcode (uCode) patch method to support runtime persistent update, as illustrated by the BIOS flash layout depicted forBIOS flash device 824 corresponding to the BIOS flash layout of diagram 300 inFIG. 3 . -
Platform hardware 802 includes aprocessor 806 having a System on a Chip (SoC) architecture including a central processing unit (CPU) 808 withM processor cores 810, each coupled to aLevel 1 and Level 2 (L1/L2)cache 812. Each of the processor cores and L1/L2 caches are connected to aninterconnect 814 to which each of amemory interface 816 and a Last Level Cache (LLC) 818 is coupled, forming a coherent memory domain. Memory interface is used to accesshost memory 804 in which various software components are loaded and run via execution of associated software instructions onprocessor cores 810. -
Processor 806 further includes an Input/Output (I/O) interconnect hierarchy, which includes one or more levels of interconnect circuitry and interfaces that are collectively depicted as I/O interconnect & interfaces 820 for simplicity. Various components and peripheral devices are coupled toprocessor 806 via respective interfaces (not all separately shown), including anetwork interface 822, aBIOS flash device 824 in which BIOS uCode is stored having a BIOS flash layout illustrated in diagram 300 and discussed above. As an option,BIOS flash device 824 may be operatively coupled toprocessor 806 via a platform controller hub (PCH) 831.Platform hardware 802 also includes a disk drive or solid state disk (SSD) withcontroller 826 in whichsoftware components 828 are stored. Optionally, all or a portion of the software components used to implement the software aspects of embodiments herein may be loaded over anetwork 829 accessed bynetwork interface 822. - During platform initialization, a current or new uCode image and various UEFI modules (not separately shown) are loaded into
host memory 804 and booted, followed loading and initialization of various software components. The software components include ahost operating system 830 and a Type-2hypervisor 831 used to host n virtual machines (VMs)VM 1,VM 2 . . . VM n, each including an operating system 432 on which one or more applications 434 are run. Platform architectures employing containers, such as Docker®-type containers, may be implemented in a similar manner. In addition, non-virtualized computing platforms that only run a single instance of an operating system may also be used. - The uCode runtime patch update approach implemented by the embodiments disclosed herein provides several advantages. First, in cases where the uCode patch comprises a OS uCode runtime patch, it enables cloud customers to update the uCode runtime patch and the persistent patch into BIOS flash region at the same time, eliminating the requirement to reset systems to apply the persistent patch into BIOS flash (and the accompanying downtime to retrieve the updated image, install it, and reboot the system). Second, the number of new BIOS packages released purely for uCode update may be reduced. This can significantly reduce cloud customer operational effort on uCode update. Third, encapsulating the uCode patch(es) into a capsule format ensures the uCode capsule image is complaint across different vendors platforms for same the CPU SKU, including support for different stepping versions. This also provide the flexibility and simplicity for cloud customer to adopt different security options.
- 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. It should be understood that these terms are not intended as synonyms for each other. 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. If the specification or claims refer to “an additional” element, that does not preclude there being more than one of the additional element.
- Italicized letters, such as ‘M’, ‘n’, etc. in the foregoing detailed description are used to depict an integer number, and the use of a particular letter is not limited to particular embodiments. Moreover, the same letter may be used in separate claims to represent separate integer numbers, or different letters may be used. In addition, use of a particular letter in the detailed description may or may not match the letter used in a claim that pertains to the same subject matter in the detailed description.
- As discussed above, various aspects of the embodiments herein may be facilitated by corresponding software and/or firmware components and applications. Thus, embodiments of this invention may be used as or to support a software program, software modules, and/or firmware (BIOS), 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.
- 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.
- The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
- These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the drawings. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/801,382 US20200192659A1 (en) | 2020-02-26 | 2020-02-26 | Modular microcode (ucode) patch method to support runtime persistent update |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/801,382 US20200192659A1 (en) | 2020-02-26 | 2020-02-26 | Modular microcode (ucode) patch method to support runtime persistent update |
Publications (1)
Publication Number | Publication Date |
---|---|
US20200192659A1 true US20200192659A1 (en) | 2020-06-18 |
Family
ID=71071141
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/801,382 Pending US20200192659A1 (en) | 2020-02-26 | 2020-02-26 | Modular microcode (ucode) patch method to support runtime persistent update |
Country Status (1)
Country | Link |
---|---|
US (1) | US20200192659A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20210103662A1 (en) * | 2020-12-18 | 2021-04-08 | Chinmay Ashok | Techniques for restricted deployment of targeted processor firmware updates |
US20220156377A1 (en) * | 2020-11-19 | 2022-05-19 | Microsoft Technology Licensing, Llc | Firmware runtime patch secure release process |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100115202A1 (en) * | 2008-11-03 | 2010-05-06 | Zimmer Vincent J | Methods and systems for microcode patching |
US20140040605A1 (en) * | 2012-08-01 | 2014-02-06 | William T. Futral | Methods and apparatus for performing secure bios upgrade |
US20150178071A1 (en) * | 2013-12-19 | 2015-06-25 | Novell, Inc. | Runtime patching of an operating system (os) without stopping execution |
US20170010875A1 (en) * | 2015-07-10 | 2017-01-12 | Dell Products, Lp | Method for Deploying BIOS Integrity Measurement via BIOS Update Package and System Therefor |
US20200082090A1 (en) * | 2018-09-10 | 2020-03-12 | Dell Products, Lp | Multi-stage Firmware Update Method and System Therefor |
US10684843B1 (en) * | 2017-09-28 | 2020-06-16 | American Megatrends International, Llc | Firmware updates using updated firmware files in a dedicated firmware volume |
US10936300B1 (en) * | 2019-06-06 | 2021-03-02 | Amazon Technologies, Inc. | Live system updates |
-
2020
- 2020-02-26 US US16/801,382 patent/US20200192659A1/en active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100115202A1 (en) * | 2008-11-03 | 2010-05-06 | Zimmer Vincent J | Methods and systems for microcode patching |
US20140040605A1 (en) * | 2012-08-01 | 2014-02-06 | William T. Futral | Methods and apparatus for performing secure bios upgrade |
US20150178071A1 (en) * | 2013-12-19 | 2015-06-25 | Novell, Inc. | Runtime patching of an operating system (os) without stopping execution |
US20170010875A1 (en) * | 2015-07-10 | 2017-01-12 | Dell Products, Lp | Method for Deploying BIOS Integrity Measurement via BIOS Update Package and System Therefor |
US10684843B1 (en) * | 2017-09-28 | 2020-06-16 | American Megatrends International, Llc | Firmware updates using updated firmware files in a dedicated firmware volume |
US20200082090A1 (en) * | 2018-09-10 | 2020-03-12 | Dell Products, Lp | Multi-stage Firmware Update Method and System Therefor |
US10936300B1 (en) * | 2019-06-06 | 2021-03-02 | Amazon Technologies, Inc. | Live system updates |
Non-Patent Citations (1)
Title |
---|
Kranz, Garry, "United Extensible Firmware Interface (UEFI)", TechTarget, last retrieved from https://www.techtarget.com/whatis/definition/Unified-Extensible-Firmware-Interface-UEFI on 30 September 2023 (Year: 2021) * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220156377A1 (en) * | 2020-11-19 | 2022-05-19 | Microsoft Technology Licensing, Llc | Firmware runtime patch secure release process |
WO2022108713A1 (en) * | 2020-11-19 | 2022-05-27 | Microsoft Technology Licensing, Llc | Firmware runtime patch secure release process |
US20210103662A1 (en) * | 2020-12-18 | 2021-04-08 | Chinmay Ashok | Techniques for restricted deployment of targeted processor firmware updates |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11941391B2 (en) | Microcode(uCode) hot-upgrade method for bare metal cloud deployment | |
EP3479224B1 (en) | Memory allocation techniques at partially-offloaded virtualization managers | |
US9626181B2 (en) | Systems and methods to securely inject binary images and code into firmware | |
CN102207896B (en) | Virtual machine crash file generation techniques | |
JP5174110B2 (en) | Automated modular secure boot firmware update | |
US8839221B2 (en) | Automatic acquisition and installation of software upgrades for collections of virtual machines | |
Zimmer et al. | Beyond BIOS: developing with the unified extensible firmware interface | |
JP5307196B2 (en) | Providing a system integrated with silicon code | |
EP4012553B1 (en) | Secure and efficient microcode(ucode) hot-upgrade for bare metal cloud | |
US20140026124A1 (en) | Updating software | |
US10303458B2 (en) | Multi-platform installer | |
US10747526B2 (en) | Apparatus and method to execute prerequisite code before delivering UEFI firmware capsule | |
WO2021158359A1 (en) | Firmware update patch | |
JP2011238277A (en) | High integrity firmware | |
CN107577937B (en) | Application program protection method and system | |
KR20140109401A (en) | Backing up firmware during initialization of device | |
US20200356358A1 (en) | Systems and methods for incrementally and dynamically updating firmware | |
US20200192659A1 (en) | Modular microcode (ucode) patch method to support runtime persistent update | |
US20160275290A1 (en) | Dynamic Firmware Module Loader in a Trusted Execution Environment Container | |
CN107077342B (en) | Firmware module operation authority | |
CN113268447A (en) | Computer architecture and access control, data interaction and safe starting method in computer architecture | |
US20210103662A1 (en) | Techniques for restricted deployment of targeted processor firmware updates | |
US20220019426A1 (en) | Method device and system for upgradable microcode (ucode) loading and activation in runtime for bare metal deployment | |
Rahman et al. | Xeon phi system software | |
US11995452B2 (en) | Firmware memory map namespace for concurrent containers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: APPLICATION DISPATCHED FROM PREEXAM, NOT YET DOCKETED |
|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUMAR, MOHAN J;JAYAKUMAR, SARATHY;SONG, CHUAN;AND OTHERS;SIGNING DATES FROM 20200306 TO 20200326;REEL/FRAME:053602/0145 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STCT | Information on status: administrative procedure adjustment |
Free format text: PROSECUTION SUSPENDED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STCV | Information on status: appeal procedure |
Free format text: NOTICE OF APPEAL FILED |
|
STCV | Information on status: appeal procedure |
Free format text: APPEAL BRIEF (OR SUPPLEMENTAL BRIEF) ENTERED AND FORWARDED TO EXAMINER |