Hello,
I'm interested in trying to capture keyboard events by causing them to generate SMIs, and then writing my own handler for the SMIs. This is for a research project on trusted path mechanisms, so it may seem a little strange. Please bear with me. :-)
I'm hoping somebody on this mailing list can offer some advice.
The approach I am considering uses USB support for legacy operating systems, where USB-related interrupts can be diverted to SMI. Typically, they are handled by the BIOS. I would modify coreboot to implement the necessary handler. There is a well-defined protocol for handing off control from the BIOS to a USB-aware OS driver, and I would write my code such that it will perform this handoff only under certain conditions.
However, I am concerned about a malicious OS simply trampling on the USB controller (via its memory-mapped and/or PCI space interfaces).
From Revision 1.0 of the USB EHCI spec, Section 5.1:
"The OS driver initiates an ownership request by setting the OS Owned semaphore to a one. The OS waits for the BIOS Owned bit to go to a zero before attempting to use the EHCI controller. The time that OS must wait for BIOS to respond to the request for ownership is beyond the scope of this specification."
"If the BIOS has set SMI on OS Ownership Change in the USBLEGCTLSTS register to a one, it receives an SMI when the OS Driver sets the OS Owned semaphore to a one. BIOS observes that OS has changed the value of the OS Owned bit..."
What happens if the BIOS doesn't relinquish control of the EHCI? Does hardware somehow prevent the OS from accessing the USB controller? What happens if the OS tries to use the USB controller without using these semaphores at all? It seems to me that the OS can at least cause a Denial-of-Service by sending commands to the USB controller, but I suspect it can also eavesdrop on keyboard events. Can anybody confirm or deny this attack?
If this is outside the scope of coreboot, I'm sorry for bothering the list.
Thank you for your time, -Jon