Subject: Re: Crypto leaks across HyperThreaded CPUs (i386, P4, HTT+SMP only)
To: None <tech-security@NetBSD.org>
From: KAMADA Ken'ichi <email@example.com>
Date: 07/04/2005 10:12:32
At Fri, 1 Jul 2005 18:49:48 +0900 (JST),
SODA Noriyuki <firstname.lastname@example.org> 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
KAMADA Ken'ichi <email@example.com>