-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "SODA" == SODA Noriyuki <soda@sra.co.jp> writes:
    >> 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.

    SODA> Isn't this vulnerability caused by the fact that spying
    SODA> process and spyed process are sharing the cache for
    SODA> cryptographic processing?  If so, how about moving such

  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.

  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.

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQslTKIqHRg3pndX9AQFnQwP/X0qvfquGUDp52fbgMydTfBYNV0aYCBpc
/H7DyVgY9JV6R3gO1TPvBXdfFeXYa55TAGpNZnUjWRF7MawPj3iG2alYsZNm5FGr
pRj/SsHSbS6UybWug9ZYEfHDo6k4f7MwSL3flP6gCF5/KChrOkXyNpfZhu5CG8b3
4HsAWnKo+Q0=
=H0ci
-----END PGP SIGNATURE-----