Messages in this thread | | | Date | 16 May 2005 13:04:00 +0200 | Date | Mon, 16 May 2005 13:03:59 +0200 | From | Andi Kleen <> | Subject | Re: Hyper-Threading Vulnerability |
| |
> 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.
> 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.
-Andi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |