Secure application firmware environment for X86 and non-X86 processors
Techniques for firmware providing a simulated system management mode (SMM) while being executed by a non-x86 platform, such as an ARM platform. In response to receiving a service call from an OS interface driver, the firmware may determine a requested service identified by the service call. Thereafter, the firmware may identify an appropriate service handler to perform the requested service. After the appropriate service handler performs the requested service, the appropriate service handler notifies the OS interface driver. Since the SMM is emulated by the firmware, the firmware may execute on an x86 platform or a non-x86 platform, such as an ARM platform.
1. A method for providing firmware services, comprising:
firmware providing a simulated system management mode (SMM) while being executed by two or more physical ARM processors by performing:
in response to receiving a service call from an OS interface driver, determining a requested service identified by the service call,
wherein the service call contains an attribute used to determine whether all but one physical processing core should be suspended when processing the service call;
the OS interface driver suspends all but one processing physical core when issuing the service call, wherein one or more physical processing cores are suspended by the OS interface driver;
identifying an appropriate service handler to perform the requested service;
after the appropriate service handler performs the requested service, the appropriate service handler notifying the OS interface driver; and
in response to the OS interface driver receiving the notification, the OS interface driver releasing any suspended physical processing cores, wherein said any suspended physical processing cores includes at least one physical processing core.
2. The method of claim 1 , wherein determining is performed by a SAFE dispatcher using a unique identifier associated with the service call.
3. The method of claim 1 , wherein identifying is performed by a SAFE dispatcher, and wherein the appropriate service handler is selected by the SAFE dispatcher from a plurality of service handlers registered with the SAFE dispatcher.
4. The method of claim 1 , wherein the OS interface driver makes the service call using an entry point address exposed by an ACPI table.
5. The method of claim 1 , wherein the OS interface driver issues the service call in response to a communication received from an OS application.
6. The method of claim 1 , wherein the OS interface driver issues the service call in response to a communication received from an OS system event dispatcher.
7. The method of claim 1 , wherein the service call involves a timer managed by the OS interface driver.
8. The method of claim 1 , wherein the service call involves a transition to a different sleep state.
9. The method of claim 1 , wherein source code for the firmware is capable of executing on an x86 platform without modification.
10. The method of claim 1 , wherein the one or more processors are each a ARM7 processor, and wherein the simulated system management mode (SMM) operates as a client of a monitor component that manages a TrustZone environment provided by the one or more processors.
11. The method of claim 1 , wherein the one or more processors are each a ARM7 processor, and wherein the simulated system management mode (SMM) operates as a monitor component that manages a TrustZone environment provided by the one or more processors.
12. A non-transitory machine-readable storage medium storing one or more sequences of instructions, which when executed by one or more processors, causes:
firmware providing a simulated system management mode (SMM) while being executed by two or more physical ARM processors by performing:
in response to receiving a service call from an OS interface driver, determining a requested service identified by the service call,
wherein the service call contains an attribute used to determine whether all but one physical processing core should be suspended when processing the service call;
the OS interface driver suspending all but one processing physical core when issuing the service call, wherein one or more physical processing cores are suspended by the OS interface driver;
identifying an appropriate service handler to perform the requested service;
after the appropriate service handler performs the requested service, the appropriate service handler notifying the OS interface driver; and
in response to the OS interface driver receiving the notification, the OS interface driver releasing any suspended physical processing cores, wherein said any suspended physical processing cores includes at least one physical processing core.
13. The non-transitory machine-readable storage medium of claim 12 , wherein identifying is performed by a SAFE dispatcher, and wherein the appropriate service handler is selected by the SAFE dispatcher from a plurality of service handlers registered with the SAFE dispatcher.
14. The non-transitory machine-readable storage medium of claim 12 , wherein the OS interface driver makes the service call using an entry point address exposed by an ACPI table.
15. The non-transitory machine-readable storage medium of claim 12 , wherein the OS interface driver issues the service call in response to a communication received from an OS application.
16. The non-transitory machine-readable storage medium of claim 12 , wherein the OS interface driver issues the service call in response to a communication received from an OS system event dispatcher.
17. The non-transitory machine-readable storage medium of claim 12 , wherein source code for the firmware is capable of executing on an x86 platform without modification.