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

Re: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources



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 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.

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.

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?

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.

Benoit

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
-----------------------------------------------------------