AMDs new instructions for parallelism and support för side-channel attacks?

Aloha!

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

But, do you think that the opppsite is also possible, that
these 
instructions might be a possible source for information
leackage and 
vector for side-channel attacks, at least local, inter
process attacks? 
I get a weird goodie-badie feeling when reading about these
instructions...


[1] Johannes Blömer and Volker Krummel. Analysis of
countermeasures 
against access driven cache attacks on AES
http://eprint.iac
r.org/2007/282.pdf

-- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
============================================================
============
Kryptoblog - IT-säkerhet på svenska
http://www.str
ombergson.com/kryptoblog
============================================================
============

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Aloha!

Joachim Strömbergson skrev:
> Aloha!
> 
> 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
> 
> But, do you think that the opppsite is also possible,
that these 
> instructions might be a possible source for information
leackage and 
> vector for side-channel attacks, at least local, inter
process attacks? 
> I get a weird goodie-badie feeling when reading about
these instructions...
> 
> 
> [1] Johannes Blömer and Volker Krummel. Analysis of
countermeasures 
> against access driven cache attacks on AES
> http://eprint.iac
r.org/2007/282.pdf

Just wanted to add a reference with info about the AMD
announcement of 
their x86 extensions for parallelism:

http:
//www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=T
ZEX4EJZT3L1CQSNDLSCKHA?articleID=201500201

-- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
============================================================
============
Kryptoblog - IT-säkerhet på svenska
http://www.str
ombergson.com/kryptoblog
============================================================
============

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

=?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= <JoachimStrombergson.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 majordomometzdowd.com