AMDs new instructions for parallelism and
pgut001 at cs.auckland.ac.nz
pgut001 at cs.auckland.ac.nz
Sun Aug 19 03:44:28 EDT 2007
=?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= <Joachim at Strombergson.com> writes:
>I just saw om EE Times that AMD will start to extend their x86 CPUs with
>instructions to support/help developers take advantage of the increasing
>(potential) parallelism in their processors. First out are two instructions
>that allows the developer to get info about instruction completion as well as
>cache misses.
>
>Considering the article by . about analysis of protection mechanism against
>cache based timing attacks for AES [1] one could assume that these
>instructions should be useful for writing side-channel resistant
>implementations
I think it's exactly the opposite, we're already having enough problems with
microarchitectural (MA) attacks without explicit diagnostic facilities built
into the CPU. If you look at the AMD specs these extra ring3-accessible
facilities are only going to make it worse. These attacks are essentially
impossible to defend against merely by modifying the victim code, the only
possible defences at the moment are:
1. "Don't do that then" (i.e. don't allow arbitrary untrusted code to run in
parallel with your crypto ops).
2. With future hardware support, some mechanism for partitioning the CPU so
that critical regions of code can run without leaving externally observable
traces, ending with some sort of super-INVD/INVLPG instruction to clear all
caches and buffers. So the code would be something like:
enter_secure_region
[[[crypto code]]]
INV_everything
exit_secure_region
Of course something like this would have to be accessible from ring 3,
which makes it a built-in DoS mechanism.
So "don't do that then" seems to be the only fix for this (not including the
usual blue-sky response of everyone having <insert-crypto-gadget-du-jour>
built into their system).
Peter.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list