Dynamic firmware module loader in a trusted execution environment container

Patent metadata

Field	Value
Publication number	US-10430589-B2
Application number	US-201514662415-A
Country	US
Kind code	B2
Filing date	Mar 19, 2015
Priority date	Mar 19, 2015
Publication date	Oct 1, 2019
Grant date	Oct 1, 2019

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.

First claim

What is claimed is:

1. A computer implemented method comprising:
providing a dynamic firmware module loader within a trusted execution environment to load and unload modules, before booting is complete, as needed from a storage containerized within a trusted execution environment including a processor within the trusted execution environment;
providing an external processor and operating system outside the trusted execution environment;
accessing the trusted execution environment before booting via an inter process communication channel rather than using a system management mode; and
abstracting storage on platform boot media, allowing different types of storage without using a storage driver for each type of storage.

2. The method of claim 1 including providing secure storage within said trusted execution environment.

3. The method of claim 2 including enabling the trusted execution environment to copy contents from platform visible memory to secure memory within the trusted execution environment.

4. The method of claim 3 including verifying data passed to said secure memory and ensuring data is accessible for a current execution context.

5. The method of claim 4 including ensuring data is persistently stored in said trusted execution environment across a power failure or reboots.

6. The method of claim 1 including determining when control is transferred from firmware to an operating system.

7. The method of claim 6 including directly updating platform visible memory using a trusted execution environment storage driver before control is transferred to the operating system.

8. The method of claim 7 including after transferring control to the operating system, triggering an upstream inter process communication channel, with no dependency on use of a system management mode, to a secure trusted execution environment driver that calls an operating system storage driver to access the platform visible storage.

9. The method of claim 1 including using the modules to provide storage or access driver capabilities to be run in a containerized environment.

10. One or more non-transitory computer readable media storing instructions executed by a processor to perform a sequence comprising:
providing a containerized storage within a trusted execution environment including a processor within the trusted execution environment;
providing a dynamic firmware module loader within a trusted execution environment to load and unload modules, before booting is complete, as needed from said containerized storage;
providing an external processor and operating system outside the trusted execution environment;
accessing the trusted execution environment before booting via an inter process communication channel rather than using a system management mode; and
abstracting storage on platform boot media, allowing different types of storage without using a storage driver for each type of storage.

11. The media of claim 10 , said sequence including providing secure storage within said trusted execution environment.

12. The media of claim 11 , said sequence including enabling the trusted execution environment to copy contents from platform visible memory to secure memory within the trusted execution environment.

13. The media of claim 12 , said sequence including verifying data passed to said secure memory and ensuring data is accessible for a current execution context.

14. The media of claim 13 , said sequence including ensuring data is persistently stored in said environment across a power failure or reboots.

15. The media of claim 10 , said sequence including determining when control is transferred from firmware to an operating system.

16. The media of claim 15 , said sequence including directly updating platform visible memory using a trusted execution environment storage driver before control is transferred to the operating system.

17. The media of claim 16 , said sequence including after transferring control to the operating system, triggering an upstream inter process communication channel with no dependency on use of a system management mode to a secure trusted execution environment driver that calls an operating system storage driver to access the platform visible storage.

18. An apparatus comprising:
a trusted execution environment;
a secure storage within the trusted execution environment;
processor within the trusted execution environment; and
a hardware processor to implement the trusted execution environment and to provide dynamic firmware module loader within a trusted execution environment to load and unload modules, before booting is complete, as needed from the secure storage, provide an external processor and operating system outside the trusted execution environment, and to access the trusted execution environment before booting via an inter process communication channel rather than using a system management mode, and abstract storage on the secure storage, allowing different types of storage without using a storage driver for each type of storage.

19. The apparatus of claim 18 , said processor to enable the trusted execution environment to copy contents from platform visible memory to the secure memory within the trusted execution environment.

20. The apparatus of claim 19 , said processor to verify data passed to said secure memory and ensuring data is accessible for a current execution context.

21. The apparatus of claim 20 , said processor to ensure data is persistently stored in said environment across a power failure or reboots.

22. The apparatus of claim 18 , said processor to determine when control is transferred from firmware to an operating system.

23. The apparatus of claim 22 , said processor to directly update platform visible memory using a trusted execution environment storage driver before control is transferred to the operating system.

24. The apparatus of claim 23 , after transferring control to the operating system, said processor to trigger an upstream inter process communication channel with no dependency on use of a system management mode to a secure trusted execution environment driver that calls an operating system storage driver to access the platform visible storage.

Assignees

• Intel Corp

Inventors

• Kotary Karunakara
• Zimmer Vincent J
• Brenden Scott D
• Benchimol Jose
• Kumar Panner
• Poornachandran Rajesh

Classifications

• G06F21/575 Primary

  Secure boot · CPC title

• G06F21/74

  operating in dual or compartmented mode, i.e. at least one secure mode · CPC title