[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources



Hi Benoit,

Thank you for the feedback.

On Sep 26, 2013, at 4:07 AM, Benoit Jacob <bjacob@mozilla.com> wrote:

> 
> As I tried to phrase on the github pull request, I have a concern with
> the naming of this extension: it is named after what the extension is
> trying to achieve (provide safe WebGL access to sensitive resources),
> rather than after what the extension actually does and how it aims to
> achieve this goal (define a "non-vulnerable-to-timing-attacks" subset of
> GLSL).

I thought of the name as what the extension is trying to provide- the concept of security sensitive resources and their input, output, and usage rules. I suppose there are two main parts to what the extension: (1) the GLSL restrictions and (2) the security sensitive resource management. The current name reflects more of #2. I think you prefer a name that reflects more of #1. I'm having trouble thinking of a name to reflect both #1 and #2.

> 
> I also have the same concerns as before about the feasibility of
> defining a non-vulnerable-to-timing-attacks subset of GLSL. Recently I
> looked into how non-constant-timing arithmetic instructions were on
> common CPUs, and wrote this study:
> 
> https://wiki.mozilla.org/User:Bjacob/ArithmeticTimingDifferences
> 
> The gist of it is that as soon as one uses any kind of floating point
> instructions (even SSE instructions), on all usual CPUs, new and old,
> x86 and ARM, there are significant timing differences in many FP
> instructions depending on the operands' values. The consequence for your
> proposal is that it one had to implement it on a CPU (as opposed to a
> GPU), one would have to use only integer arithmetic (and even then, one
> would have to avoid integer divisions too). In other words, it is
> impossible to implement WEBGL_security_sensitive_resources reasonably
> efficiently in a software renderer.

First of all, thank you very much for conducting that research- I've found it very informative. I agree that it would be difficult to implement GLSL with fixed-point CPU arithmetic. Personally, I'm fine with the extension not working on devices where the GPU is unavailable or blacklisted.

> 
> I have not looked into the situation in GPUs, but given what the
> above-mentioned study showed about CPUs, and how it contradicted common
> knowledge about how timing differences were supposed to be a thing of
> the past since SSE was introduced, I would be cautious and I'd say that
> if you would like to promote this extension, you need to conduct such a
> study on many common GPUs, see which ones have reliable enough
> constant-time execution of arithmetic instructions, to make it actually
> a safe target to run with WEBGL_security_sensitive_resources on.

Yes, this seems like a logical next step. I'm interested in creating a GPU timing test suite.

> 
> A further difficulty of GPUs compared to CPUs is that at least on CPUs
> we can control exactly which instructions are run, which is often key to
> getting constant-time behavior. For example, we can rewrite an if()
> branching with masking instead, or we can carefully avoid a given
> instruction. On GPUs, we only get to give the driver a shader to
> compile... there is an opaque, client-specific optimizing compiler here.
> How do we e.g. prevent it from optimizing code in a way that makes it
> non-constant-time, e.g. by rewriting masking into actual branching?

Yes, this is definitely a challenge. I would like an extension from hardware vendors that when enabled, guarantees there are no optimizations which introduce timing differences in primitive operations. Currently, without knowing proprietary GPU implementation details, I hypothesize that this is already true for many operations on many GPUs. I've done informal testing on some GPUs and haven't found any timing differences in primitive operations yet. However, we need a test suite to verify this hypothesis on a variety of hardware.

> 
> So before this extension can be safely exposed anywhere by a browser, I
> think that a prerequisite is to conduct a study of what hardware and
> drivers it actually can run on, and based on results from it, maybe one
> could construct a whitelist/blacklist.

Agreed.

> 
> Benoit

- Max

> 
> On 13-09-25 07:50 PM, Max Vujovic wrote:
>> Hi all,
>> 
>> I'd like to propose an extension that allows WebGL to process security sensitive content. In summary, the extension allows authors to upload cross-origin resources as textures and run a restricted shading language on their content. The shading language is restricted in order to prevent timing attacks. Authors can use both regular and security sensitive content in the same WebGL context.
>> 
>> The concept of security sensitive resources can be used to bring HTML content into WebGL in a future extension.
>> 
>> Here is a link to proposal: 
>> http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_security_sensitive_resources/
>> 
>> This proposal is related to the discussion last November:
>> https://www.khronos.org/webgl/public-mailing-list/archives/1211/msg00058.html
>> 
>> I think enabling custom, accelerated effects on arbitrary content opens a whole world of creative possibilities on the web platform. 
>> 
>> Feedback welcome!
>> 
>> Thanks,
>> Max
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
>> 
> 
> 
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
> 


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------