> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
