At Fri, 1 Jul 2005 18:49:48 +0900 (JST),
SODA Noriyuki <soda@sra.co.jp> wrote:
> 
> > 		 NetBSD Security Advisory 2005-001
> > Topic: Crypto leaks across HyperThreaded CPUs (i386, P4, HTT+SMP only)
> 
> > Later potential workarounds:
> >
> > 1. Reimplement all cryptographic code to use constant time, and constant
> > cache-access execution patterns. There is some interest along these
> > lines from various groups, as a result of this issue.  NetBSD's Security
> > Officers will monitor the availability of such code.
> 
> Isn't this vulnerability caused by the fact that spying process and spyed
> process are sharing the cache for cryptographic processing?
> If so, how about moving such sensitive code to private memory space
> (e.g. allocate anonymous memory for each process, copy the code to the
> anonymous memory, and make the memory read-only and executable) to
> prevent to share the cache?

Does that prevent the spying and spyed processes from sharing the
cache (here, sharing == competing the cache space)?  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).

-- 
KAMADA Ken'ichi <kamada@nanohz.org>