Date: Thu, 08 Nov 2007 23:25:40 -0800 From: Colin Percival <cperciva@freebsd.org> To: Nate Lawson <nate@root.org> Cc: cvs-src@FreeBSD.org, Kris Kennaway <kris@FreeBSD.org>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c Message-ID: <47340B74.9070004@freebsd.org> In-Reply-To: <47337940.6040909@root.org> References: <200711081945.lA8JjKcW080540@repoman.freebsd.org> <47337724.9040108@FreeBSD.org> <47337940.6040909@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson wrote: > I'm still waiting for what will be done to prevent the attack on > uniprocessor or multi-core machines (shared L2). Continuing to focus on > hyperthreading is like locking the screen door on your submarine. Exploiting the a cache collision channel through the L2 cache is much harder than through the L1 cache, and is likely impossible under many circumstances (OpenSSL has been fixed to prevent the most easily exploitable cache side channel). In addition, there are other attacks, e.g., using shared branch prediction tables, to which hyperthreaded processors are vulnerable but which do not affect multicore systems at all. Rather than locking the screen door on a submarine, I'd say that a more apt comparison would be turning off a fire hydrant even though a garden hose is still running. I recommend the use of more sophisticated countermeasures against side channel attacks where highly sensitive keying material is concerned; but this does not invalidate the utility of applying such a very simple countermeasure which prevents a very easy attack. Colin Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47340B74.9070004>