Abstract: Particular embodiments described herein provide for an electronic device that can receive data from an operating system in an electronic device, where the data is related to hardware that is in communication with the electronic device through a multimodal interface and communicate the data and/or related data to a local policy manager, where the local policy manager is in communication with the multimodal interface. The multimodal interface can be configured to support power transfers, directionality, and multiple input/output (I/O) protocols on the same interface.

Abstract: 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.

Abstract: Technologies for fast low-power startup include a computing device with a processor having a power management integrated circuit. The computing device initializes platform components into a low-power state and determines, in a pre-boot firmware environment, the battery state of the computing device. The computing device determines a minimum-power startup (MPS) configuration that identifies platform components to be energized and determines whether the battery state is sufficient for the MPS configuration. If sufficient, the computing device energizes the platform components of the MPS configuration and boots into an MPS boot mode. In the MPS boot mode, the computing device may execute one or more user-configured application(s). If the battery state is sufficient for normal operation, the computing device may boot into a normal mode. In the normal mode, the user may configure the MPS configuration by selecting features for the future MPS boot mode. Other embodiments are described and claimed.

Abstract: In one embodiment, a system includes: a processor; a security processor to execute in a trusted executed environment (TEE), the security processor to execute memory reference code (MRC) stored in a secure storage of the TEE to train a memory coupled to the processor; and the memory coupled to the processor. Other embodiments are described and claimed.

Abstract: A mechanism is described for facilitating dynamic capsule generation and recovery in computing environments according to one embodiment. A method of embodiments, as described herein, includes accessing a current firmware and a capsule driver binary file (“capsule file”) from a storage device, and merging the current firmware with the capsule file and a capsule header into a capsule payload. The method may further include assigning a security protocol to the capsule payload to ensure a secured capsule payload, and storing the secured capsule payload at the storage device for subsequent updates.

Abstract: Technologies for processor core soft-offlining include a computing device having a processor with multiple processor cores. On boot, an operating system queries a firmware interface to retrieve a potential offline set of processor cores. The operating system prevents the processor cores of the potential offline set from receiving device interrupts. The computing device detects a platform management event from the firmware interface and, in response to the platform management event, queries the firmware interface to determine a requested offline set of processor cores. Each of the processor cores in the requested offline set is included in the potential offline set. The computing device brings the processor cores of the requested offline set into a low-power state, and then the computing device may start performing a platform management operation. The platform management event may include a memory hot-plug event or a specialized workload event. Other embodiments are described and claimed.

Abstract: Generally, this disclosure provides systems, devices, methods and computer readable media for a Unified Extensible Firmware Interface (UEFI) with durable storage to provide memory write persistence, for example, in the event of power loss. The system may include a processor to host the firmware interface which may be configured to control access to system variables in a protected region of a volatile memory. The system may also include a power management circuit to provide power to the processor and further to provide a power loss indicator to the firmware interface. The system may also include a reserve energy storage module to provide power to the processor in response to the power loss indicator. The firmware interface is further configured to copy the system variables from the volatile memory to a non-volatile memory in response to the power loss indicator.

Abstract: Methods, apparatuses and storage medium associated with providing firmware to a device are disclosed herein. In various embodiments, an apparatus may include a device, and a processor to host a computing environment that includes the device and a device driver of the device. Further, the apparatus may include a firmware agent, disposed outside the computing environment, to provide, on behalf of the device driver, firmware to the device on power-on of the device. Other embodiments may be described and claimed.

Abstract: Technologies for securely booting a computing device includes a security engine of the computing device that consecutively determines a hash value for each block of initial boot firmware and generates an aggregated hash value from the hash value determined for each of the blocks. A processor of the computing device determines whether the aggregated hash value matches a reference checksum value. Initialization of the processor is completed in response to a determination that the aggregated hash value matches the reference checksum value. In some embodiments, the security engine consecutively retrieves each block of the initial boot firmware from a memory of the computing device, stores each retrieved block in a secure memory of the security engine, and determines the hash value for each stored block. Each block stored in the secure memory is copied to a portion of a cache memory of the processor initialized as Cache as RAM.

Abstract: Various embodiments are generally directed to an apparatus, method and other techniques to receive port configuration information from a radio frequency identification (RFID) device, the port configuration information indicating whether one or more I/O ports are permitted or unpermitted for use and perform a verification of an I/O port of one or more I/O ports based on the port configuration information stored in the RFID device. Embodiments also include causing an action to occur based on whether the I/O port has been verified or not verified.

Abstract: 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.

Abstract: 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.

Abstract: Technologies for fast low-power startup include a computing device with a processor having a power management integrated circuit. The computing device initializes platform components into a low-power state and determines, in a pre-boot firmware environment, the battery state of the computing device. The computing device determines a minimum-power startup (MPS) configuration that identifies platform components to be energized and determines whether the battery state is sufficient for the MPS configuration. If sufficient, the computing device energizes the platform components of the MPS configuration and boots into an MPS boot mode. In the MPS boot mode, the computing device may execute one or more user-configured application(s). If the battery state is sufficient for normal operation, the computing device may boot into a normal mode. In the normal mode, the user may configure the MPS configuration by selecting features for the future MPS boot mode. Other embodiments are described and claimed.

Abstract: Techniques of debugging a computing system are described herein. The techniques may include generating debug data at agents in the computing system. The techniques may include recording the debug data at a storage element, wherein the storage element is disposed in a non-core portion of the circuit interconnect accessible to the agents.

Abstract: Generally, this disclosure provides systems, devices, methods and computer readable media for a Unified Extensible Firmware Interface (UEFI) with durable storage to provide memory write persistence, for example, in the event of power loss. The system may include a processor to host the firmware interface which may be configured to control access to system variables in a protected region of a volatile memory. The system may also include a power management circuit to provide power to the processor and further to provide a power loss indicator to the firmware interface. The system may also include a reserve energy storage module to provide power to the processor in response to the power loss indicator. The firmware interface is further configured to copy the system variables from the volatile memory to a non-volatile memory in response to the power loss indicator.

Abstract: Techniques of debugging a computing system are described herein. The techniques may include generating debug data at agents in the computing system. The techniques may include recording the debug data at a storage element, wherein the storage element is disposed in a non-core portion of the circuit interconnect accessible to the agents.

Abstract: Methods, apparatuses and storage medium associated with providing firmware to a device are disclosed herein. In various embodiments, an apparatus may include a device, and a processor to host a computing environment that includes the device and a device driver of the device. Further, the apparatus may include a firmware agent, disposed outside the computing environment, to provide, on behalf of the device driver, firmware to the device on power-on of the device. Other embodiments may be described and claimed.