Abstract: A disclosed example apparatus includes memory; and at least one processor to execute first instructions, the first instructions obtained from first encrypted firmware, the at least one processor to: encrypt handoff data with an original equipment manufacturer key to generate encrypted handoff data; decrypt second encrypted firmware based on the original equipment manufacturer key to generate second instructions; and provide access to the encrypted handoff data to the second instructions, the second instructions to perform initialization of a computer based on the handoff data obtained from the encrypted handoff data.

Abstract: A disclosed example apparatus includes memory; and at least one processor to execute first instructions, the first instructions obtained from first encrypted firmware, the at least one processor to: encrypt handoff data with an original equipment manufacturer key to generate encrypted handoff data; decrypt second encrypted firmware based on the original equipment manufacturer key to generate second instructions; and provide access to the encrypted handoff data to the second instructions, the second instructions to perform initialization of a computer based on the handoff data obtained from the encrypted handoff data.

Abstract: A pre-boot initialization technique for a computing system allows for encrypting both a manufacturer and original equipment manufacturer firmware routines, as well as handing off data between the manufacturer and original equipment manufacturer firmware routines encrypted with a key provisioned in field programmable fuses with an original equipment manufacturer key. By encrypting the firmware routines and handoff data, security of the pre-boot initialization process is enhanced. Original equipment manufacturer updatable product data may also be encrypted with the original equipment manufacturer key. Additional security may be provided by using trusted input/output capabilities of a trusted execution environment to display information to and receive information from a user. Furthermore, multiple secure phases of configuration may be achieved using wireless credentials exchange components.

Abstract: An embodiment includes an apparatus comprising: an out-of-band cryptoprocessor coupled to secure non-volatile storage; and at least one storage medium having firmware instructions stored thereon for causing, during runtime and after an operating system for the apparatus has booted, the cryptoprocessor to (a) store a key within the secure non-volatile storage, (b) sign an object with the key, while the key is within the cryptoprocessor, to produce a signature, and (c) verify the signature. Other embodiments are described herein.

Abstract: Techniques for providing and maintaining protection of firmware routines that form part of a chain of trust through successive processing environments. An apparatus may include a first processor component (550); a volatile storage (562) coupled to the first processor component; an enclave component to, in a pre-OS operating environment, generate a secure enclave within a portion of the volatile storage to restrict access to a secured firmware loaded into the secure enclave; a first firmware driver (646) to, in the pre-OS operating environment, provide a first API to enable unsecured firmware to call a support routine of the secured firmware from outside the secure enclave; and a second firmware driver (647) to, in an OS operating environment that replaces the pre-OS operating environment, provide a second API to enable an OS of the OS operating environment to call the support routine from outside the secure enclave.

Abstract: Methods, apparatus, systems and articles of manufacture are disclosed to improve boot efficiency. An example apparatus includes a firmware support package (FSP) configuration engine to retrieve an FSP reset (FSP-R) component from a platform memory, a firmware interface table (FIT) manager to assign an entry to a FIT for the FSP-R component and assign respective entries to the FIT for auxiliary FSP components, and an FSP configuration engine to transfer platform control to the FSP-R component to control execution of the auxiliary FSP components in response to a platform reset vector.

Abstract: Technologies for pre-memory phase initialization include a computing device having a processor with a cache memory. The computing device may determine whether a temporary memory different from the cache memory of the processor is present for temporary memory access prior to initialization of a main memory of the computing device. In response to determining that temporary memory is present, a portion of the basic input/output instructions may be copied from a non-volatile memory of the computing device to the temporary memory for execution prior to initialization of the main memory. The computing device may also initialize a portion of the cache memory of the processor as Cache as RAM for temporary memory access prior to initialization of the main memory in response to determining that temporary memory is not present. After initialization, the main memory may be configured for subsequent memory access. Other embodiments are described and claimed.

Abstract: A pre-boot initialization technique for a computing system allows for encrypting both a manufacturer and original equipment manufacturer firmware routines, as well as handing off data between the manufacturer and original equipment manufacturer firmware routines encrypted with a key provisioned in field programmable fuses with an original equipment manufacturer key. By encrypting the firmware routines and handoff data, security of the pre-boot initialization process is enhanced. Original equipment manufacturer updatable product data may also be encrypted with the original equipment manufacturer key. Additional security may be provided by using trusted input/output capabilities of a trusted execution environment to display information to and receive information from a user. Furthermore, multiple secure phases of configuration may be achieved using wireless credentials exchange components.

Abstract: A method for booting a data processing system (DPS) involves, during a boot process of the DPS, using a preliminary bootcode module from a low-speed nonvolatile memory (NVM) in the DPS to load a main bootcode module from a high-speed NVM in the DPS into a volatile random access memory (RAM) in the DPS, wherein the high-speed NVM supports a read speed that is faster than a maximum read speed of the low-speed NVM. The method also involves, during the boot process, after loading the main bootcode module from the high-speed NVM into the RAM, using the main bootcode module to boot the DPS to an operating system (OS). The method may also involve using the preliminary bootcode module to automatically determine whether the main bootcode module from the high-speed NVM has good integrity. Other embodiments are described and claimed.

Abstract: Various embodiments are generally directed to establishing trust in system management mode. An operating system management mode driver can invoke a system management mode and provide a signature to the system management mode to authenticate the driver with. Additionally, a hash value of the driver can be used to determine whether the driver is authorized to invoke system management mode or particular operations or features of system management mode.

Abstract: Technologies for hybrid sleep power management include a computing device with a processor supporting a low-power idle state. In a pre-boot firmware environment, the computing device reserves a memory block for firmware use and copies platform wake code to a secure memory location, such as system management RAM (SMRAM). At runtime, an operating system may execute with the processor in protected mode. In response to a request to enter a sleep or suspend state, the computing device generates a system management interrupt (SMI). In an SMI handler, the computing device copies the wake code from SMRAM to the reserved memory block. The computing device resumes from the SMI handler to the wake code with the processor in real mode. The wake code enters the low-power idle state and then jumps to a wake vector of the operating system after receiving a wake event. Other embodiments are described and claimed.

Abstract: Techniques for providing and maintaining protection of firmware routines that form part of a chain of trust through successive processing environments. An apparatus may include a first processor component (550); a volatile storage (562) coupled to the first processor component; an enclave component to, in a pre-OS operating environment, generate a secure enclave within a portion of the volatile storage to restrict access to a secured firmware loaded into the secure enclave; a first firmware driver (646) to, in the pre-OS operating environment, provide a first API to enable unsecured firmware to call a support routine of the secured firmware from outside the secure enclave; and a second firmware driver (647) to, in an OS operating environment that replaces the pre-OS operating environment, provide a second API to enable an OS of the OS operating environment to call the support routine from outside the secure enclave.

Abstract: A method for booting a data processing system (DPS) involves, during a boot process of the DPS, using a preliminary bootcode module from a low-speed nonvolatile memory (NVM) in the DPS to load a main bootcode module from a high-speed NVM in the DPS into a volatile random access memory (RAM) in the DPS, wherein the high-speed NVM supports a read speed that is faster than a maximum read speed of the low-speed NVM. The method also involves, during the boot process, after loading the main bootcode module from the high-speed NVM into the RAM, using the main bootcode module to boot the DPS to an operating system (OS). The method may also involve using the preliminary bootcode module to automatically determine whether the main bootcode module from the high-speed NVM has good integrity. Other embodiments are described and claimed.

Abstract: Various embodiments are generally directed to establishing trust in system management mode. An operating system management mode driver can invoke a system management mode and provide a signature to the system management mode to authenticate the driver with. Additionally, a hash value of the driver can be used to determine whether the driver is authorized to invoke system management mode or particular operations or features of system management mode.

Abstract: An embodiment includes an apparatus comprising: an out-of-band cryptoprocessor coupled to secure non-volatile storage; and at least one storage medium having firmware instructions stored thereon for causing, during runtime and after an operating system for the apparatus has booted, the cryptoprocessor to (a) store a key within the secure non-volatile storage, (b) sign an object with the key, while the key is within the cryptoprocessor, to produce a signature, and (c) verify the signature. Other embodiments are described herein.

Abstract: Methods, apparatus, systems and articles of manufacture are disclosed to improve boot efficiency. An example apparatus includes a firmware support package (FSP) configuration engine to retrieve an FSP reset (FSP-R) component from a platform memory, a firmware interface table (FIT) manager to assign an entry to a FIT for the FSP-R component and assign respective entries to the FIT for auxiliary FSP components, and an FSP configuration engine to transfer platform control to the FSP-R component to control execution of the auxiliary FSP components in response to a platform reset vector.

Abstract: An embodiment includes an apparatus comprising: an out-of-band cryptoprocessor coupled to secure non-volatile storage; and at least one storage medium having firmware instructions stored thereon for causing, during runtime and after an operating system for the apparatus has booted, the cryptoprocessor to (a) store a key within the secure non-volatile storage, (b) sign an object with the key, while the key is within the cryptoprocessor, to produce a signature, and (c) verify the signature. Other embodiments are described herein.

Abstract: Various embodiments are generally directed to establishing trust in system management mode. An operating system management mode driver can invoke a system management mode and provide a signature to the system management mode to authenticate the driver with. Additionally, a hash value of the driver can be used to determine whether the driver is authorized to invoke system management mode or particular operations or features of system management mode.

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: Technologies for pre-memory phase initialization include a computing device having a processor with a cache memory. The computing device may determine whether a temporary memory different from the cache memory of the processor is present for temporary memory access prior to initialization of a main memory of the computing device. In response to determining that temporary memory is present, a portion of the basic input/output instructions may be copied from a non-volatile memory of the computing device to the temporary memory for execution prior to initialization of the main memory. The computing device may also initialize a portion of the cache memory of the processor as Cache as RAM for temporary memory access prior to initialization of the main memory in response to determining that temporary memory is not present. After initialization, the main memory may be configured for subsequent memory access. Other embodiments are described and claimed.