Re: Hyper-Threading Vulnerability

[ebiederm@xmission.com (Eric W. Biederman)]

Andi Kleen <ak@muc.de> writes:

> > The only solution I have seen proposed so far that seems to work
> > is to not schedule untrusted processes simultaneously with 
> > the security code.  With the current API that sounds like
> > a root process killing off, or at least stopping all non-root
> > processes until the critical process has finished.
> 
> With virtualization and a hypervisor freely scheduling it is quite 
> impossible to guarantee this. Of course as always the signal 
> is quite noisy so it is unclear if it is exploitable in practical 
> settings. On virtualized environments you cannot use ps to see
> if a crypto process is running. 

Interesting.  I think that is a problem for the hypervisor maintainer.
Although that is about enough to convince me to request a
OS flag that says "please give me privacy" and later that can be passed
down to the hypervisor.  My gut feel is running under a hypervisor
is when things will at their most vulnerable.

Where this is a threat is when there will be a lot of RSA
key transactions.  At which point it is likely that the attacker
can reproduce enough of the setup to figure out the fine details.

I think discovering a crypto process will simply be a matter
finding a https sever.  As for getting the timing how about
initiating a https connection?  Getting rid of the noise will certainly
be a challenge but you will have multiple attempts.

> > And those same processors will have the same problem if the share
> > significant cpu resources.  Ideally the entire problem set
> > would fit in the cache and the cpu designers would allow cache
> > blocks to be locked but that is not currently the case.  So a shared
> > L3 cache with dual core processors will have the same problem.
> 
> At some point the signal gets noisy enough and the assumptions
> an attacker has to make too great for it being an useful attack.
> For me it is not even clear it is a real attack on native Linux, at 
> least the setup in the paper looked highly artifical and quite impractical. 
> e.g. I suppose it would be quite difficult to really synchronize
> to the beginning and end of the RSA encryptions on a server that
> does other things too.

Possibly.  But then buffer overflow attacks when you don't know the exact
stack layout are similarly difficult and ways have been found.  And if
you have multiple chances things get easier.  And if you are aiming
at something easier then brute forcing a private key even the littlest
bit is a help.

When people mmap pages we zero them for the same reason so that
we don't have unintentional information leaks.

I agree that for now because little is known this is a highly specialized
attack.  However the trend is now towards increasingly big SMP's.
That increases the number of resources that can be shared so the
possibility of a problem increases.  At the rate Intel's cpus are
going we may see throttling of one cpu core when the other one
generates too much heat, because it is busy doing something else cpu
intensive.  And other optimizations lead to much easier to imagine
vulnerabilities.

As for noise with the area cpu designers are getting into things
are becoming increasingly fine grained so information is leaking
at an increasingly fine level.  As the L2 cache issue has shown
that information starts to leak below the level an application
designer has control of.  At which point things get very difficult
to manage.  

Information leaks are more difficult than simply gaining root on
the box where you can simply take the information you want.  But
that means that is exactly where a locked down well administered
box will be vulnerable if a way is not found to avoid the problem.
I don't know what the consequences of having your private key
discovered are, but I have never heard a case where identity theft
was something pleasant to fix.

Eric