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

Re: [Public WebGL] CORS and resource provider awareness



On Sun, Nov 4, 2012 at 5:16 PM, David Sheets <kosmo.zb@gmail.com> wrote:
> Hi Ken,
>
> Some thoughts inline...
>
> On Tue, Oct 30, 2012 at 12:54 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> Nobody's code would be broken.
>>
>> The idea, a variant of which Gregg Tavares has posted before to this
>> mailing list, would be:
>>
>>   - A WebGLRenderingContext would start life with a "shader_clean" bit set.
>>
>>   - The "shader_clean" bit continues to be set so long as all shaders
>> loaded into the WebGLRenderingContext obey the timing restrictions set
>> in the ANGLE patch.

Hi David,

> This analysis will be unnecessary in very many use cases. Should it be
> run for every shader?
>
> If I have a same-origin web game that loads 256 shader permutations,
> why should they all be checked for timing attacks?

Fair questions. I believe the dataflow analysis computing the
"shader_clean" bit is so cheap that it could be done all the time
without significantly impacting the startup or run-time performance of
any real-world application. Shader translation and validation is
already a mandatory step when loading WebGL shaders.


>>   - While the "shader_clean" bit is set:
>>
>>     - It is legal to upload cross-domain media into WebGL textures.
>> Doing so taints the canvas and prevents toDataURL(), readPixels(),
>> etc., as the pre-CORS WebGL spec did.
>>
>>   - If the "shader_clean" bit transitions from true to false, and any
>> cross-domain media was uploaded as a texture, then the context would
>> be lost.
>
> Could the shader fail to compile instead? Context loss is pretty harsh.

That's a good point. Yes, I think it could. I hadn't thought of that
possibility.


>>   - If the "shader_clean" bit was false, the existing CORS
>> restrictions would be enforced.
>>
>> This would not break any existing programs. It would, however, allow
>> cross-domain media to be used in conjunction with a set of useful
>> WebGL shaders.
>
> Here's what I propose:
> Shaders which are intended to not branch on texture data should
> declare something like
>
> #extension WEBGL_BRANCH_RC : disable
>
> where 'WEBGL_BRANCH_RC' (Restricted Content?) is a strawman name for
> an implicit extension that is enabled by default in ESSL right now.
>
> Shaders which do not disable this extension ('intension'?) do not have
> the branch analysis performed and always unset the "shader_clean" bit.
> Shaders which disable this extension (as above) will error on compile
> if they branch on potentially unprivileged data.
>
> With this approach, use of the subset of the language that is safe is
> explicitly declared in shaders and shader authors and users can tell
> at-a-glance whether the shader obeys the timing restrictions. To
> instruct their tools to find violations, authors can say:
>
> #extension WEBGL_BRANCH_RC : warn
>
> Here are the state transitions for the shader_clean and tainted bits.
> The state is represented by (shader_clean, tainted) with the start
> state as (true, false):
>
> (true, false) --CORS upload--> (true, false)
> (true, false) --(BRANCH_RC : disable) upload--> (true, false)
> (true, false) --non-CORS upload--> (true, true)
> (true, false) --(BRANCH_RC : enable) upload--> (false,false)
>
> (true, true) --(BRANCH_RC : enable) upload--> #fail_compile
>
> (false, false) --non-CORS upload--> #fail_upload

Thanks, this is a useful tabulation of the states.


> Where other transitions are identity for these state bits.
>
> CSS shaders would then be required to disable the extension. This
> might break shaders which currently do:
>
> #extension all : disable
>
> but AFAIK no one does this on the web (why would you?! but "all :
> warn" would get more useful) and these shaders should arguably be
> broken if they branch on texture data because they no longer use the
> minimal feature set for the platform.
>
> What do you think?

Interesting idea, and a possibility. It seems to me that the main
motivation for adding a GLSL extension would be to be able to skip the
analysis altogether. I think the cost of the dataflow analysis should
be measured first before adding more extensions and complexity. If we
were to go down the route of defining a GLSL extension then I think it
should be one disabled by default, enabled manually, and which
indicates intent to produce a shader obeying the control flow
restrictions. The shader compilation log would still provide detail on
why any shaders failing that analysis did so.

-Ken

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