dealing with a malicious OS

[Jonathan M. McCune]

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

[Peter Stuge]

On Fri, Apr 18, 2008 at 12:07:00PM -0400, Jonathan M. McCune wrote:
> What happens if the BIOS doesn't relinquish control of the EHCI?

A well-behaved OS will wait.
An ill-behaved OS will try to exploit.
> Does hardware somehow prevent the OS from accessing the USB
> controller?

Hardware can never know which software (firmware or OS) is accessing
the 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?

A malicious OS could poll the controller frequently in order to
eavesdrop on firmware<->hw communication, but the eavesdropping is a
race condition, since firmware and OS probably will not execute in
parallell.

A malicious OS could certainly feed constant junk to a controller in
order to disrupt any firmware use.

The semaphore is only a convenience primitive for use by cooperating
firmware and OS.
> If this is outside the scope of coreboot, I'm sorry for bothering
> the list.

Mh, well maybe just a little. :)

//Peter