Abstract: A root of trust may include one or more hardware components of an IHS (Information Handling System) that operate using validated hardware instructions. Once a root of trust has been established, it may be extended by validating additional components and the instructions by which these components operate. A chain of trusted boot components may be used to securely initialize a set of components required to support core functions of the IHS. In order to detect components of a trusted boot chain that have been compromised, boot chain components validate their own instructions as well as the instructions to be utilized by the next boot component and the instructions utilized by the prior boot component, thus providing bidirectional validation of trusted boot chain components.

Abstract: A system initiates a boot operation that executes firmware, and retrieves an anti-roll back version table stored by a trusted platform module. The system determines that the firmware is invalid based on the anti-roll back version table retrieved from the trusted platform module, and aborts the boot operation in response to the determining that the firmware is invalid based on the anti-roll back version table.

Abstract: An established root of trust supports a secure execution environment (SEE) that supports execution of validated software instructions on behalf of trust domains that operate within the SEE to implement functions and to support hardware supported by the IHS. Embodiments support isolated operation of such trust domains within the SEE while avoiding the overhead of isolation within separate software environment enclaves. Signed instructions for the operation of a trust domain are retrieved and authenticated based on a signing token associated with the trust domain. If authenticated, the trust domain is granted access to resources set forth in a privilege policy token linked to the signing token of the trust domain. The privileges assigned to a trust domain may be modified by linking the trust domain's signing token to a new privilege policy token.

Abstract: A system initiates a boot operation that executes firmware, and retrieves an anti-roll back version table stored by a trusted platform module. The system determines that the firmware is invalid based on the anti-roll back version table retrieved from the trusted platform module, and aborts the boot operation in response to the determining that the firmware is invalid based on the anti-roll back version table.

Abstract: A root of trust may include one or more hardware components of an IHS (Information Handling System) that operate using validated hardware instructions. Once a root of trust has been established, it may be extended by validating additional components and the instructions by which these components operate. A chain of trusted boot components may be used to securely initialize a set of components required to support core functions of the IHS. In order to detect components of a trusted boot chain that have been compromised, boot chain components validate their own instructions as well as the instructions to be utilized by the next boot component and the instructions utilized by the prior boot component, thus providing bidirectional validation of trusted boot chain components.

Abstract: An established root of trust supports a secure execution environment (SEE) that supports execution of validated software instructions on behalf of trust domains that operate within the SEE to implement functions and to support hardware supported by the IHS. Embodiments support isolated operation of such trust domains within the SEE while avoiding the overhead of isolation within separate software environment enclaves. Signed instructions for the operation of a trust domain are retrieved and authenticated based on a signing token associated with the trust domain. If authenticated, the trust domain is granted access to resources set forth in a privilege policy token linked to the signing token of the trust domain. The privileges assigned to a trust domain may be modified by linking the trust domain's signing token to a new privilege policy token.