Intel Corporation

Scott D Brenden

Suresh K Marisetty

Koichi Yamada

Kushagra V Vaid

Rajendra Kuramkote

Vincent J Zimmer

Rajesh Poornachandran

Karunakara Kotary

Mohan J Kumar

James B Crossland

Shivnandan D Kaushik

Andrew J Fish

Jose Andy Vargas

William Cheung

Panner Kumar

Yaron Shragai

Jose Benchimol

A dynamic firmware module loader loads one of a plurality of a firmware contexts or modules as needed in a containerized environment for secure isolated execution. The modules, called applets, may be loaded and unloaded in a firmware context. The loader may use a hardware inter process communication channel (IPC) to communicate with the secure engine. The modules may be designed to implement specific features desired by basic input/output system vendors, without the use of a system management mode. Designed modules may provide necessary storage and I/O access driver capabilities to be run in trusted execution environment containers.

Dynamic firmware module loader in a trusted execution environment container

Systems, apparatuses and methods may provide for receiving, from a host driver, factory data including one or more of calibration data, platform identifier data, manufacturer data or wireless carrier data, and verifying integrity of the factory data. Additionally, the factory data may be provisioned into non-volatile memory (NVM) in accordance with an operating system independent format managed by a platform root-of-trust such as a Trusted Execution Environment (TEE). In one example, provisioning the factory data includes defining one or more partitions in the NVM, initiating storage of the factory data to the NVM along the one or more partitions, and specifying a restriction profile for the one or more partitions, wherein the restriction profile includes one or more of read restrictions, write restrictions, time bound restrictions or location bound restrictions.

Secure trusted execution environment data store

Disclosed is a communication mechanism among hardware, firmware and system software in order to redirect interrupts or other hardware events to only one thread execution context of an error domain for a multi-threaded processing system. Other embodiments are also described and claimed.

Method and apparatus for redirection of machine check interrupts in multithreaded systems

A system and method for injecting hardware errors into a microprocessor system is described. In one embodiment, a software interface between system software and system firmware is established. Software test and debug for software error handlers may thus be supported. The software interface may support both a query mode call and a seed mode call. When a query mode call is issued, it may request whether or not the system firmware and hardware support the injection of a specified kind of error. A return from this call may be used to make a list of supported errors for injection. When a seed mode call is issued, the corresponding error may be injected into the hardware.

System and method for error injection using a flexible program interface field

Methods and architectures for performing hardware error handling using coordinated operating system (OS) and firmware services. In one aspect, a firmware interface is provided to enable an OS to access firmware error-handling services. Such services enable the OS to access error data concerning platform hardware errors that may not be directed accessed via a platform processor or through other conventional approaches. Techniques are also disclosed for intercepting the processing of hardware error events and directing control to firmware error-handling services prior to attempting to service the error using OS-based services. The firmware services may correct hardware errors and/or log error data that may be later accessed by the OS or provided to a remote management server using an out-of-band communication channel. In accordance with another aspect, the firmware intercept and services may be performed in a manner that is transparent to the OS.

OS and firmware coordinated error handling using transparent firmware intercept and firmware services

Use of data poisoning techniques may permit proactive operating system recovery without needing to always bringing down the operating system when uncorrectable errors are encountered.

Poisoned error signaling for proactive OS recovery

A processing system may include an operating system (OS) and one or more specialized error handling modules to be registered with the OS after the processing system is powered on. The OS may also include a master policy module. The specialized error handling module may collect error data from a component of the processing system, and may generate abstracted error data, based at least in part on the collected error data. The master policy module may determine a recovery action to be taken, based at least in part on the abstracted error data. The OS may also include an error collection routine that calls one or more specialized error handling modules in response to detecting a hardware error. The error collection routine may also retrieve information from firmware in response to detecting the hardware error. Other embodiments are described and claimed.

Growing community of inventors

Hillsboro, OR, United States of America

Scott D Brenden