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

Re: [Public WebGL] CORS and resource provider awareness



I believe SSE still has performance problems with denormal numbers unless flush-to-zero is enabled, and I'm not sure that's enabled in all software renderers (llvmpipe, swiftshader, and apple's).


On Mon, Nov 5, 2012 at 12:21 PM, Kenneth Russell <kbr@google.com> wrote:

Florian, very nice proofs of concept. They certainly imply that
texture fetches in vertex shaders would have to be disallowed (already
specified in http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security#Method_H:_Tainting_shader_code_branches
) as well as dependent texture fetches (which was known from earlier
work, but, it seems, not mentioned in that specification).

While enforcing data flow constraints would certainly restrict the
kinds of rendering algorithms that can be implemented, there are great
benefits and use cases from being able to work with cross-domain media
from WebGL, even in this restricted setting. I think the benefits are
so great that it is worth continuing to invest work in this area -- if
for no better reason that it is clear that some major content
providing sites will never support anonymous CORS requests, so the
WebGL community may as well invest some time in figuring out
alternatives to be able to utilize such media. At the same time, we
should work with media serving sites to get as much CORS support in
place as is feasible and safe.

Benoit, your concerns are noted. However, you will recall that there
have been subsequent discussions with every major desktop GPU vendor
-- including Intel -- and the issue with slow NaN handling doesn't
exist in the SSE instruction set, nor in any current GPU by AMD, Intel
or NVIDIA. I think investigation is needed to understand whether there
are realistically timing differences that can be measured in the
implementations of other functions such as trigonometric functions.

This entire path of investigation is certainly fragile. I appreciate
the comparison to a leaky sieve. I would expect this functionality to
be exposed as a WebGL extension, not in the core API, and we would
expect to need to turn it off many times as new attacks are
discovered. Nonetheless, I think that if we collectively invest time
and effort to try to break the planned restrictions, that we might
determine a good subset of GLSL that can be used with cross-domain
media. Of course, if anyone has completely different ideas that would
also enable access to the desired media in an even safer manner,
please propose them.

-Ken


On Mon, Nov 5, 2012 at 9:10 AM, Florian Bösch <pyalot@gmail.com> wrote:
> - Normalmapped environment lookups
> - Parallax mapping
> - GPU based terrain rendering
> - virtual texturing
> - detail texturing (some variants)
> - signed depth field effects
>
>
> On Mon, Nov 5, 2012 at 4:19 PM, Florian Bösch <pyalot@gmail.com> wrote:
>>
>> On Mon, Nov 5, 2012 at 3:40 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
>>>
>>> My understanding is that the proposed restrictions on the shader language
>>> already ban dependent texture lookups, so that they should be able to block
>>> this particular attack.
>>
>> Banning texture dependent lookups also breaks a lot of other usecases such
>> as:
>> - FXAA
>> - depth based blurs
>> - SSAO
>> - variance shadow maps
>> - optimizations based on texture baked data
>> - dithering
>> - etc.
>
>

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