[cap-talk] DMA vs programmed I/O (was: Midori in The Register)

[Kenneth Hamer-Hodges]

Just in from Black-Hat on the same theme. If confirmed it is another pointer
that shows why hardware capabilities are the right foundation to trusted
security.

Researchers say they have found a way to bypass Vista's memory protection
features:
http://searchsecurity.techtarget.com.au/articles/26194-Black-Hat-roundup-Vis
ta-security-defeated-IOS-rootkit-DNS-flaw-worse-than-thought-#Vista 
k
> -----Original Message-----
> From: Kenneth Hamer-Hodges [mailto:ken at sipantic.net]
> Sent: Wednesday, August 06, 2008 7:20 PM
> To: 'General discussions concerning capability systems.'
> Subject: RE: [cap-talk] DMA vs programmed I/O (was: Midori in The
> Register)
> 
> In the absence of any real data to press this discussion far I can
> certainly claim that
> 1. The number of cores would be more numerous per unit area if the real-
> estate was focused on only one style of typed hardware - perhaps double.
> 2. The additional code and real-time required to set up 'typed' I/O tasks
> and deal with DMA interrupts adds accidental performance overheads.
> 3. The use of DMA contorts the natural - intrinsic - flow of control and
> added various scheduling delay points that also have an impact.
> 4. The style lead back to privileged modes and that is a very slippery
> slope that eventually leads back to the problems we presently face.
> 
> One only has to see the mess we have on our hands with virtualization
> hardware and Rutkowska's finding on Blue Pill to become a believer - see
> http://theinvisiblethings.blogspot.com/
> In conclusion I see the performance argument as misguided when considered
> with respect to internet I/O and TCB security issues. (btw I am not
> against a high performance DMA instruction as was developed for System
> 250).
> k
> 
> > -----Original Message-----
> > From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
> > bounces at mail.eros-os.org] On Behalf Of David-Sarah Hopwood
> > Sent: Wednesday, August 06, 2008 5:34 PM
> > To: General discussions concerning capability systems.
> > Subject: [cap-talk] DMA vs programmed I/O (was: Midori in The Register)
> >
> > Kenneth Hamer-Hodges wrote:
> > > Adding a second DMA version of typed hardware leads to a second set of
> > > mechanism at risk and question about delegation to the DMA level open
> up
> > > another Pandora's Box.
> > > With multi core solution so easily available today this simplicity and
> > > uniformity remain the best option for building a Trusted Computer
> Base.
> >
> > Given that existing systems use DMA, and obtain a significant
> performance
> > advantage from doing so *for any given number of cores*, and that new
> > systems must be able to compete on performance, it seems unlikely that a
> > new system design that was unable to use DMA could be successful.
> >
> > I don't often make arguments in favour of performance at the expense of
> > simplicity, but here the performance advantage (perceived and actual) is
> > just too great. For a system using programmed I/O to be able to compete,
> > the hardware would need to have enough general-purpose cores that you
> > don't have anything worthwhile to do with some of them apart from I/O.
> > Even that assumes that the required I/O bandwidth won't increase as the
> > number of cores does, which is probably not a valid assumption,
> > especially for the applications that are most in need of high
> performance.
> >
> > If anything, the importance of having specialized I/O "cores" (whether
> > or not they look like conventional DMA controllers) increases with
> > multicore, because this specialization is a more efficient use of the
> > available chip area and power budget: a general-purpose core is area-
> > and power-inefficient for doing I/O, and an I/O core can't be made
> > to do general computation without increasing its area and power usage.
> > Actually it makes some sense to further specialize the I/O cores to
> > handle specific physical-layer protocols, as the Tile64
> > <http://www.tilera.com/products/processors.php> does, for example.
> > (I have no connection with Tilera.)
> >
> > --
> > David-Sarah Hopwood
> > _______________________________________________
> > cap-talk mailing list
> > cap-talk at mail.eros-os.org
> > http://www.eros-os.org/mailman/listinfo/cap-talk