Re: [Xen-devel] HT Vulnerability CAN-2005-0109

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > This vulnerability could (in principle) affect isolation between Xen VMs.
> > It's not clear how exploitable it is, though.
>
> It's clear that it is very exploitable.

On a real world system?

"To ensure that the two processes run simultaneously, we start running the Spy 
process before we start OpenSSL, and stop it after OpenSSL has ïnished, while 
minimizing the number of other processes running"

That's fine as a proof of concept but it's not the real world.  Note that I'm 
not denying a persistent attacker may still capture a key eventually, even in 
a very "noisy" environment.  The barrier to successful exploit may be 
substantially increased, however.

> > Covert channels will *always* be there.
>
> Yes. As you say, the problem is the side channel attack, not the covert
> channel.

The covert channel is still a problem if it's substantially higher bandwidth 
than the inevitable pre-existing channels.  For the XenSE work with mandatory 
access control we can't eliminate covert channels but we'd like them not to 
be high bandwidth.

> > Someone has yet to release code that'll actually exploit these
> > theoretical holes, so it's not clear how big a problem is in practice.
>
> Huh? That sounds like something I would expect to hear from a Microsoft
> marketroid.

Thank you for your insight, David.

> The paper includes code for the side channel attack (Figure 1 
> in <http://www.daemonology.net/papers/htt.pdf>), and even if it didn't, it
> would be easy to replicate.

I admit I hadn't noticed the code included could be used in the side channel 
attack - it's a fair cop guv!  It's worrying - we should watch what the other 
OS communities do on this.

Regards,
Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel