W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2011

Constant-time subsets of GLSL (was Re: Documenting Timing Attacks in Rendering Engines)

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 12 Dec 2011 23:10:02 -0800
Message-ID: <CAJE5ia9bN_mHqiniAo1CsKjXQ3qPykZdKLx2r-6etAH6ygszCQ@mail.gmail.com>
To: Ralph Thomas <ralpht@gmail.com>
Cc: James Robinson <jamesr@google.com>, Chris Marrin <cmarrin@apple.com>, "Gregg Tavares (wrk)" <gman@google.com>, Vincent Hardy <vhardy@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
On Mon, Dec 12, 2011 at 9:56 PM, Ralph Thomas <ralpht@gmail.com> wrote:
> On the topic of "constant time GLSL", I was thinking that any value
> derived from a texture sample read from web content would be
> "poisoned" so it could not be used for conditionals and that the
> poison would propagate to any dependent value in the program. You
> could assign a poisoned value to gl_FragColor (obviously) but could
> not branch or loop on it.
> This would still let you write blur kernels, do lighting effects and
> warp texture coordinates, but you wouldn't be able to use any part of
> the texture as a lookup table, for example.

In principle, this approach can work.  To be fully correct, the
program should be restricted to performing constant-time operations on
tainted values.  However, just avoiding branches is probably a good
place to start.

> It should be possible to add a pass to ANGLE to poison values read
> from texture and those dependent on them and then validate that no
> selections or loops depend on a poisoned value. I think that a program
> that passed this test would then always execute in the same time for a
> given set of vertices regardless of the contents of any bound texture.
> I believe CSS Shaders would still be useful with these limitations
> added to GLSL -- what did I miss?

I would encourage you to implement a prototype of this scheme to see
whether you can still write useful shaders.  Some OpenGL experts I
talked with earlier claimed that this approach would be too
restrictive, but that's something that's easy to experiment with.

Received on Tuesday, 13 December 2011 07:11:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:39 UTC