Subject: Re: Crypto leaks across HyperThreaded CPUs (i386, P4, HTT+SMP only)
To: Michael Richardson <firstname.lastname@example.org>
From: SODA Noriyuki <email@example.com>
Date: 07/05/2005 21:51:35
>>>>> On Mon, 04 Jul 2005 10:12:32 +0900,
"KAMADA Ken'ichi" <firstname.lastname@example.org> said:
> As far as I read the paper, it is not the source of this problem
> that the identical code shares the cache (here, shares == lives in
> the cache as one instance).
>>>>> On Mon, 04 Jul 2005 11:18:01 -0400,
Michael Richardson <email@example.com> said:
> No, it is due to the fact that they are sharing the cache at all.
> The process doing the cryptographic operations reveals whether it is
> doing *2 or +1 operations by the pattern of memory accesses it does.
> The spying process is noticing when the pattern by the fact that it's
> accesses to memory are slowed in different fashions by the need to fill
> the cache for the cryptographic process.
Hmm, I see. Thanks.
> Read the paper.
> My suggestion: provide a system call that grabs the "big lock" and
> prevents SMP for the duration of the call. We'd need a capability bit,
> since we might not want to restrict this to root.
Also, ideally our scheduler should know the virtual processors which are
sharing same cache...