Secure driver platform

1. A system for providing a secure driver framework comprising:

a hardware processor to:

manage an unsecure operating system execution environment comprising a first user mode and a first kernel mode;

manage a secure execution environment comprising a second user mode and a second kernel mode;

based at least in part on a system call from an unsecure driver in the first kernel mode or the first user mode, the secure execution environment to:

create a secure device node corresponding to a reported new hardware device;

load a secure driver corresponding to the secure device node, the secure driver to enable accessing a configuration space of the new hardware device and loading advanced configuration and power interface tables in the second kernel mode; and

notify the unsecure operating system execution environment indicating a second unsecure driver is to be loaded for the new hardware device the second unsecure driver to report the new hardware device in response to an indication of accessing the configuration space; and

provide one or more system services of the second kernel mode to the secure driver.

2. The system of claim 1 , wherein the unsecure driver transmits the system call to the secure driver via a remote procedure call.

3. The system of claim 1 , wherein the processor is to enumerate a secure device by creating a second secure device node and loading the second secure driver in the second user mode of the secure execution environment.

4. The system of claim 1 , wherein the processor is to:

parse a memory mapped table in the second kernel mode of the secure execution environment;

map the configuration space for the secure execution environment;

launch the unsecure driver in the first kernel mode of the unsecure operating system execution environment; and

enumerate a secure device in the first kernel mode.

5. The system of claim 4 , wherein the advanced configuration and power interface tables comprise a memory mapped configuration space base address description table (MCFG) and a secure device table.

6. The system of claim 5 , wherein the processor is to:

transmit a request for configuration space access from the first kernel mode of the unsecure operating system execution environment to the second kernel mode of the secure execution environment;

modify the configuration space of the secure execution environment; and

transmit a result of the modification of the configuration space to the first kernel mode of the unsecure operating system execution environment.

7. The system of claim 1 , wherein the processor is to:

detect an interrupt via the first kernel mode of the unsecure operating system execution environment; and

transmit a remote procedure call to the secure driver in the second user mode of the secure execution environment, wherein the remote procedure call indicates the detected interrupt.

8. The system of claim 1 , wherein the processor is to provide, via the second kernel mode of the secure execution environment, a direct memory access library to the second user mode, the direct memory access library enabling buffer allocation and direct read or write operations corresponding to a secure device.

9. The system of claim 1 , wherein the processor is to enable the unsecure driver to modify a subset of device memory.

10. The system of claim 1 , wherein the secure driver enables the unsecure driver to communicate with a secure device.

11. A method for providing a secure driver framework comprising:

managing an unsecure operating system execution environment comprising a first user mode and a first kernel mode;

managing a secure execution environment comprising a second user mode and a second kernel mode, wherein based at least in part on a system call from an unsecure driver in the first kernel mode or the first user mode, the secure execution environment comprises:

creating a secure device node corresponding to a reported new hardware device;

loading a secure driver corresponding to the secure device node, the secure driver to enable accessing a configuration space of the new hardware device and loading advanced configuration and power interface tables in the second kernel mode; and

notifying the unsecure operating system execution environment indicating a second unsecure driver is to be loaded for the new hardware device, the second unsecure driver to report the new hardware device in response to an indication of accessing the configuration space; and

providing one or more system services of the second kernel mode to the secure driver.

12. The method of claim 11 , wherein the unsecure driver transmits the system call to the secure driver via a remote procedure call.

13. The method of claim 11 , comprising enumerating a secure device by creating a second secure device node and loading the second secure driver in the second user mode of the secure execution environment.

14. The method of claim 11 , comprising:

parsing a memory mapped table in the second kernel mode of the secure execution environment;

mapping the configuration space for the secure execution environment;

launching the unsecure driver in the first kernel mode of the unsecure operating system execution environment; and

enumerating a secure device in the first kernel mode.

15. The method of claim 14 , wherein the advanced configuration and power interface tables comprise a memory mapped configuration space base address description table (MCFG) and a secure device table.

16. The method of claim 15 , comprising:

transmitting a request for configuration space access from the first kernel mode of the unsecure operating system execution environment to the second kernel mode of the secure execution environment;

modifying the configuration space of the secure execution environment; and

transmitting a result of the modification of the configuration space to the first kernel mode of the unsecure operating system execution environment.

17. The method of claim 11 , comprising:

detecting an interrupt via the first kernel mode of the unsecure operating system execution environment; and

transmitting a remote procedure call to the secure driver in the second user mode of the secure execution environment, wherein the remote procedure call indicates the detected interrupt.

18. The method of claim 11 , comprising providing, via the second kernel mode of the secure execution environment, a direct memory access library to the second user mode, the direct memory access library enabling buffer allocation and direct read or write operations corresponding to a secure device.

19. The method of claim 11 , comprising detecting a level of security and loading the secure driver in the first user mode or the first kernel mode of the unsecure operating system execution environment based on the level of security.

20. The method of claim 11 , comprising dynamically loading and linking the unsecure driver and the secure driver.

21. One or more computer-readable storage devices for implementing a secure driver framework comprising a plurality of instructions that, based at least on execution by a processor, cause the processor to

manage an unsecure operating system execution environment comprising a first user mode and a first kernel mode;

manage a secure execution environment comprising a second user mode and a second kernel mode, wherein based at least in part on a system call from an unsecure driver in the first kernel mode or the first user mode, the secure execution environment is to:

create a secure device node corresponding to a reported new hardware device;

load a secure driver corresponding to the secure device node, the secure driver to enable accessing a configuration space of the new hardware device and loading advanced configuration and power interface tables in the second kernel mode; and

notify the unsecure operating system execution environment indicating a second unsecure driver is to be loaded for the new hardware device the second unsecure driver to report the new hardware device in response to an indication of accessing the configuration space; and

provide one or more system services of the second kernel mode to the secure driver.

22. The one or more computer-readable storage devices of claim 21 , wherein the plurality of instructions cause the processor to:

transmit a request for configuration space access from the first kernel mode of the unsecure operating system execution environment to the second kernel mode of the secure execution environment;

modify the configuration space of the secure execution environment; and

transmit a result of the modification of the configuration space to the first kernel mode of the unsecure operating system execution environment.

23. The system of claim 1 , wherein the processor is to report the new hardware device to a plug and play device tree.