Re: How trustworthy is that I/O device?

On Wed, Nov 06, 2013 at 02:21:32PM -0800, Matt Thomas wrote:
> 
> I've always wondered why we "trust" file systems and panic they aren't
> what we expect.

Well, maybe we panic.  Didn't we see an accidental proof of concept FFS
bug that clobbered other kernel data structures a few years ago?  I
don't think denial of service is all we should worry about here.  Compared
to arbitrary code execution in the kernel, a panic seems comparatively
benign.

Whatever else was _actually_ found, the "hypersonic ultra BIOS" virus
scare does point out that device drivers are all too trusting that
devices will hand them only as much response data as they expect.  I
don't know enough about how USB host controllers work (and because I'm
running out the door to work right now, I can't look at the code this
morning!) to be sure they don't just trust peripherals out there across
the bus to not hand them more data than they're "supposed to" deliver
by DMA to the host; I've certainly seen other kinds of host adapters
get this wrong before...

The Mac OS X kernel attempts to protect itself against this sort of
thing (as well as attacks by malicious Thunderbolt peripherals once
the kernel is booted, etc.) on modern hardware (I say "attempts" because
it clearly does not and probably can not get it entirely right) by using
the IOMMU to restrict DMA to regions actually allocated as DMA target
memory.  We could do this in bus_dma on some platforms but I bet a naive
implementation would be _very_ slow.  The effect would be to force an
indirect attack -- rather than whacking kernel datastructures directly
you have to whack other data inbound by DMA and hope it gets executed.
With disk controllers in the system, eventually it probably will.

There are various threat models (like an attack on a "sleeping" laptop
by a malicious monitor/projector/dock/keyboard/etc. as it cold boots a
new kernel then "comes out of hibernation") where none of this helps
you at all, of course, unless you have trustworthy firmware that locks
down all this kind of functionality until a signed kernel boots...

This is a big scary problem space.  We could at least take some incremental
steps to do a little better.

Thor