From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hopwood Subject: Re: HT Vulnerability CAN-2005-0109 Date: Thu, 19 May 2005 18:45:41 +0100 Message-ID: <428CD0C5.7070108@blueyonder.co.uk> References: <1116427424.4496.17.camel@crusher.takatukaland.de> <200505181548.48629.mark.williamson@cl.cam.ac.uk> <428BCB21.7020909@blueyonder.co.uk> <200505190346.15609.mark.williamson@cl.cam.ac.uk> Reply-To: david.nospam.hopwood@blueyonder.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <200505190346.15609.mark.williamson@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Mark Williamson wrote: >>>This vulnerability could (in principle) affect isolation between Xen V= Ms. >>>It's not clear how exploitable it is, though. >> >>It's clear that it is very exploitable. >=20 > On a real world system? Yes. > "To ensure that the two processes run simultaneously, we start running = the Spy=20 > process before we start OpenSSL, and stop it after OpenSSL has =EF=AC=81= nished, while=20 > minimizing the number of other processes running" The only critical issue is that the crypto code and the Spy process run simultaneously on different threads of an HT processor. In a real situati= on, there are any number of ways this could be arranged. The simplest way to = get the timing right would probably be for the attacker to initiate an SSL connection himself. In the case where the attack is performed between hypervisor domains, it'= s easy for the attacker to ensure that the Spy is the only code running in his domain. > That's fine as a proof of concept but it's not the real world. The author is not attempting to do a real world attack. He's simplifying = the situation as much as possible, in order to get clean data, simple exploit= code, and a set-up that is easy to describe and reproduce. That's what yo= u always do (speaking from experience) when trying to demonstrate attacks that depend on timing. Unfortunately there is the hazard that people may think that restrictions you introduced just as a simplification, are actu= ally necessary preconditions for the attack. A real attack would be a bit more complicated, but no less feasible. > Note that I'm not denying a persistent attacker may still capture a key= > eventually, even in a very "noisy" environment. I think you're overestimating how noisy a real environment would be. Ther= e would be no interference from other processes, because an OS time slice i= n the victim domain is long enough to almost always run the whole of the cr= ypto operation (in this case a modular exponentiation). Even if it wasn't, it would be easy to recognize when a context switch occurred. Within a time slice the crypto code and the Spy are the only two processes using the shared cache. >>The paper includes code for the side channel attack (Figure 1=20 >>in ), and even if it didn't,= it >>would be easy to replicate. >=20 > I admit I hadn't noticed the code included could be used in the side ch= annel=20 > attack - it's a fair cop guv! It's worrying - we should watch what the= other=20 > OS communities do on this. I think the FreeBSD fix implements the approach suggested in the paper of= not scheduling threads with different privileges on the same HT processor= =2E In Xen, this would correspond to only giving any particular domain a whol= e HT processor. I'm not sure how that would affect performance; it could re= sult in only one thread of an HT processor being used in some cases, but OTOH = cache utilization might improve in others. --=20 David Hopwood