As computer platforms become more complex, software including basic input/output system (BIOS) and BIOS-to-operating system (OS) communication routines are being targeted for attacks. These attacks can target Advanced Configuration and Power Interface (ACPI) and Unified Extensible Firmware Interface (UEFI) runtime services. In addition to these attacks, BIOS system management mode (SMM) areas are continually growing, but the feature and subsequent memory footprint required for BIOS continually grows. In many cases this footprint is growing at a rate faster than the top segment of memory (TSEG), a reserved memory region that is visible and accessible only in SMM.
Currently the only method of protecting memory against attack is by keeping shared memory in SMM, and the OS executes a system management interrupt (SMI) to enable entry into the SMM. The BIOS will see the SMI source and perform some action on its internally protected memory, which is called system management random access memory (SMRAM) or TSEG. This has several architectural issues. First, execution of an SMI has an overhead. On the current generation of platforms, OS vendors set a 190 microsecond (μs) total time budget for handling a single SMI. Many BIOS implementations are not able to meet this requirement. Thus pushing more features and protecting memory in SMRAM is not possible. Second, not all information stored in SMRAM needs to be protected from being read. Some critical sections need protection from read and write (RW), but much of the information may only need to be protected from writes or cache attacks. Thus, TSEG as defined today is improperly organized and not scalable in an architecturally efficient manner. Another protection method is to have read-only, write-protected system board flash memory; however, this resource is limited in size and can be updated only across a reset or via SMM-based agent protection.
Embodiments enable system software, and more particularly BIOS, to carve a portion of host visible memory and mark it as read only (RO). This memory region can then be protected from being written or cached unless by an architecturally measured agent, e.g., BIOS executing in a secure context. While the scope of the present invention is not limited in this regard, logic of a processor, memory controller, and/or chipset may be used to provide the memory protection. The protected memory can be executed from and read by the OS without concern that it has been modified. Embodiments can protect various information such as critical BIOS components of the OS communication pathways without impact to platform performance by avoiding SMM overhead or read-only memory (ROM) based execution from a RO flash device. Certain embodiments are described for BIOS-to-OS communication, but without loss of generality other implementations can be applied to virtual machine monitor (VMM)-to-virtual machine (VM) or OS-to-driver communication. Also, this capability could be applied to protect other memory-mapped resources where integrity is a concern but not confidentiality (i.e., any code can read, but only a trusted agent can modify). Note that while particular embodiments herein are described in the context of BIOS, more generally implementations can exist in system firmware beyond BIOS.
Embodiments thus provide a portion of system memory as read-only memory. In the past legacy systems, so-called PC/AT systems, having a “ROM” located at 0xC0000p-0xFFFFF of an address map had emulated chipset support by allowing for these memory locations to be backed by system memory, e.g., dynamic random access memory (DRAM) and using the Memory-Attribute Registers (MAR) or the Programmable Attribute Map (PAM) registers in a chipset or uncore to protect these regions. This hardware helped with the “runtime BIOS” for PC/AT legacy.
With the advent of SMBIOS, ACPI, and Unified EFI (UEFI) runtimes, there may be swaths of memory content that come from the platform and could enjoy the protection of hardware resources in the chipset/platform. For these more modern firmware data tables and code, a secure execution mode such as original equipment manufacturer (OEM) SMM can be used to be the reference monitor/guard of these resources. Embodiments thus may be used to provide a robust and secure platform experience.
Also, for systems without SMM or that have SMM security considerations, this capability may be available at platform reset when the manufacturer system board firmware initially runs, is configured and locked prior to running any third party content (e.g., option ROM, OS loader, OS runtime). This is applicable because the provenance of the UEFI runtime, SMBIOS, ACPI should be the system board manufacturer and provisioned in the factory prior to shipping the system.
Another embodiment of the SMM software logic could be an integrated service processor in the CPU package. For example, a system on a chip can have a cryptographic co-processor integrated along with the main CPU core. Such ancillary processing units are typically called portions of an ‘uncore’ to distinguish them from the main computational core(s). This co-processor could effect the same flows as the BIOS-based SMM.
Referring now to
As shown in
This address space maps to actual physical memory within the system, which may be present in various locations including DRAM and memory present on devices, memory mapped input/output (MMIO) and so forth. As seen, compatibility region 120 may include a disk operating system (DOS) range 122, a video graphics adapter (VGA) memory 124, and a PAM region 126. In turn, low memory region 114 may map to a portion of system memory, e.g., DRAM low memory 131. Next, an RSEG region 133 in accordance with an embodiment of the present invention may be provided. In different implementations, the amount of this region may be configurable to be between approximately 1 MB (for a space constrained system like a deeply integrated system-on-a-chip) to 128 MB (for a large enterprise server). Above this region, a MMIO low region 134 may be present. Then a TSEG region 135 which may correspond to SMRAM may be present. Then various memory apertures, which may provide pointers to other memory locations may be present. Such memory apertures may include an JO advanced programmable interrupt controller (APIC) aperture 136, a trusted platform module (TPM) aperture 137, a local APIC aperture 138, and a BIOS aperture 139, which may point to a flash memory including the BIOS image.
In turn, high memory region 116 may map to memory region 140, which includes a system DRAM high memory region 142, a high RSEG region 144, along with various memory apertures such as an MMIO high region aperture 145, a reserved aperture 147, and a privileged control and status register (CSR) aperture 147. While shown with this particular implementation for example in the embodiment of
As to core 210, it can execute the RSEG region but cannot write the range unless it is executing a trusted agent. This can be accomplished by assigning the RSEG region to be read/writeable, under certain conditions. For example, BIOS SMM handlers may be used to change the RSEG region but no other entity can do so. With regard to system memory 240, the RSEG regions 245 can thus be configured by BIOS as a range carved out of a node's portion of the system address map. As seen, the region can be spread across any combination of physical or virtual RAM devices.
With respect to caching agent 220, it may operate to prevent caching of the range of the RSEG regions for non-SMM write accesses. In this way, cache attacks may be avoided. Still further, in other embodiments in addition to preventing caching of the RSEG region for non-SMM write operations, similar cache prevention may occur for non-SMM reads.
In one embodiment, the following registers can be provided. While the location of the registers can vary (and there may be multiple instantiations in some embodiments), as one example the registers may be present as part of an address decoder logic 204 of uncore logic 205 of a processor. For purposes of discussion, assume the registers can also be present in each caching agent. Of course the registers may be located in other places such as the caching logic, chipset logic and so forth. These registers define the region of RSEG in DRAM, e.g., both in lower and upper memory. Specifically, these registers include control registers to define the bounds of the protected region:
RSEGHI_BASE beginning of RSEG region in the upper 4G region [63:20] (e.g., 1 MB increments; most significant bit (MSB) can be lower than 63)
RSEGHI_LIMIT end of RSEG region in upper region
RSEGLO_BASE beginning at RSEG region in the lower 4G region [32:20] (1 MB increments)
RSEGLO_LIMIT end of RSEG region in lower region
RSEG_CTRLSTS contains an enable bit and a status bit.
In various implementations, this control register or other such registers may further include a RSEG_LOCK_PERM lock bit that is set prior to running third party code, so that RSEG protection settings cannot be changed, such as n-tuple of registers of above, by any agent later, including SMM. Note that this bit may be ignorable if a RSEG_LOCK_ONLY_SMM_ACCESSIBLE lock bit is already set. This RSEG_LOCK_ONLY_SMM_ACCESSIBLE lock bit can be set prior to running third party code, so that RSEG protection settings cannot be changed, such as n-tuple of registers of above, by any agent later other than SMM. Again, this bit may be ignorable if RSEG_LOCK_PERM is already set. These registers should be available to early system board firmware code prior to locking, and then only to SMM code after locking.
One example of information to be protected in the RSEG may be UEFI runtime services. First during power on self test (POST), BIOS will initialize memory as normal. The BIOS embodiment can include but is not limited to the security initialization (SEC), pre-EFI (PEI), and driver execution environment (DXE) phases of execution, as defined in the Platform Initialization Specifications, Volumes 1-5, available at www.uefi.org. Next, BIOS configures RSEG to be the region of memory which occupies the UEFI runtime services and loads the service into this region. Thereafter, the BIOS will lock this memory range, e.g., by setting up the boundary and control registers. This has the effect of enforcing caching agents to block/stop caching of the RSEG region. Note that BIOS SMM can execute later to change the size of the RSEG region, e.g., by updating of the boundary registers. All BIOS running up to this point has been provisioned by the platform manufacturer and is thus trusted. After setting up the region and sets the appropriate locks, BIOS boots the operating system and runs other third party code, such as UEFI or conventional PC/AT BIOS option ROM's from host-bus adapters (HBA). Then, subsequent usages of UEFI runtime services can be trusted by all platform entities because it is now RO, and immutable.
During normal system operation when an RSEG violation occurs the request is trapped (e.g., by the caching logic) and RSEG_LOCK_ONLY_SMM_ACCESSIBLE is set, the status bit is set in the RSEG control register, and an SMI is generated. When SMM code is executed, it clears the status bit and a completion for the trapped request is returned to the core, which may be in the form of a master abort such as a CRAB_ABORT (e.g., false data is generated and sent back to the requester). For systems with RSEG_LOCK_PERM set, attempts to write to a region covered by RSEG will be ignored.
If the caching logic receives either a non-SMM write or non-SMM request for ownership (which is a request to a cache to seek data in an Exclusive (E) state), it will trap the request and signal a message to generate an SMI. The request will be held until the SMM code clears the RSEG status indicator in the RSEG control register, and then the SMM is exited, allowing the caching logic to generate a CRAB_ABORT to the core. In various embodiments, caching logic will allow non-caching reads and read requests that cache in a shared (S)-state (S-state prevents writes to the cache). Thus by allowing the region to be cached only in S-state allows the code to run at full speed, but still prevents writes.
Note that SMM code may be allowed to cache the RSEG region in E-state or modified (M)-state, but thereafter the cache is flushed before returning to normal execution. Also note that the above-described registers have no effect if LIMIT=<BASE or if the enable bit in RSEG_CTRLSTS is not set. To provide full protection, SMM code may be allowed to alter the contents of these registers (using previously defined mechanisms). To enhance performance, any request originating from an input/output (IO) device will be sent to the caching logic, where it can be immediately CRAB_ABORT'd (since this came from IO, there is no need to stall a core by trapping it or signaling SMI).
Referring now to
Still referring to
Referring now to
Still referring to
Note that the operations of
Accordingly, in various embodiments, BIOS or OS can create a RO section of host memory for read and execute operations. Additionally, the RSEG region may be overriden and resized for reliability-availability-serviceability (RAS) operations like memory capacity add, memory removal, etc.
Embodiments may be implemented in many different system types. Some such systems may be personal computer (PC)-based systems such as desktops, laptops, notebooks, netbooks, or various types of server systems. However, embodiments may be implemented in other systems such as cellular telephones including so-called smart phones, personal digital assistants, mobile Internet devices, or a system based on a system-on-a-chip (SoC), and so forth.
Referring now to
Still referring to
Furthermore, chipset 690 includes an interface 692 to couple chipset 690 with a high performance graphics engine 638, by a P-P interconnect 639. In turn, chipset 690 may be coupled to a first bus 616 via an interface 696. As shown in
As discussed above, embodiments can be incorporated into other types of systems including mobile devices such as a cellular telephone. Referring now to
Applications processor 710 also may couple to a baseband processor 730 which conditions signals such as voice and data communications for output, as well as to condition incoming telephone and other signals. As seen, baseband processor 730 couples to a transceiver 740 which may enable both receive and transmit capabilities. In turn, transceiver 740 may be in communication with an antenna 750 that can be any type of antenna capable of transmitting and receiving voice and data signals via one or more communication protocols such as via a wireless wide area network (e.g., a 3G or 4G network) and/or a wireless local area network (such as a BLUETOOTH™ or so-called WI-FI™ network in accordance with an Institute of Electrical and Electronics Engineers 802.11 standard). As seen, system 700 may further include a rechargeable power supply 725 having a rechargeable battery to enable operation in a mobile environment. While shown with this particular implementation in the embodiment of
Embodiments may be implemented in code and may be stored on a storage medium having stored thereon instructions which can be used to program a system to perform the instructions. The storage medium may include, but is not limited to, any type of non-transitory storage medium, such as disk including floppy disks, optical disks, optical disks, solid state drives (SSDs), compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions
While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.