[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] CORS and resource provider awareness
On Mon, Nov 5, 2012 at 11:59 AM, Kenneth Russell <firstname.lastname@example.org> wrote:
> 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.
It appears that current prototype implementations of this analysis are
boolean over the set of all textures. See
I would like to be able to read (but not branch on) restricted content
while branching on control textures in the same shader (e.g.
functional masking). I believe this requires tracking a taintedness
bit for each sampler annotated on every storage cell in a (potentially
fused) abstract interpretation pass. Will this analysis always be all
samplers or no samplers?
As noted elsewhere in this thread, this may become quite complicated
and require AST fix-up or proof generation for floating point
Given the already high latency of shader compilation in the render
loop, I would really like to turn off this analysis unless I require
it as author.
>> 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.
An extension declaration also signals authorial intent that the
supplied program is written in a sublanguage. Without an explicit
declaration, source consumers (human or machine) have to comprehend
the code and verify that it implicitly obeys the restrictions for a
given sampler. With an explicit declaration, an error will occur
immediately upon loading a shader that does not conform to its inline
> I think the cost of the dataflow analysis should
> be measured first before adding more extensions and complexity.
The cost of this analysis will only increase as new quirks are
discovered and new techniques are applied to recover lost
I do not believe the present timing analysis in Chromium includes
support for user-defined functions.
> 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.
Below, I detail two approaches involving the extension system and
their pros and cons:
Extension : full WebGLSL ---branching restriction extension--->
sampler-linear superlanguage of GLSL
The use of an extension makes sense with some addition to the base language.
I support an extension on the condition that security is enforced via
the type system rather than changing the behavior of existing types. I
see some type attributes that look quite similar to parametric types
in GLSL, however I have no institutional knowledge of their genesis or
political feasibility as all of the GLSL mailing list archives are
I propose the creation of a new type attribute called something like
'secure' or 'restricted' or 'tainted' or 'linear'. This type attribute
could only be applied to sampler types when the extension is enabled
and would enforce branching restrictions for only those samplers.
Pros of the extension approach:
1. Explicit restriction per sampler
2. Explicit invocation of run-time analysis
3. Base language doesn't change
Cons of the extension approach:
1. No means to express a global constraint makes discovering sampler
use that obeys the extension constraint unwieldy (have to annotate
2. No means to load shaders that conform but don't declare their conformance
3. New type attribute required
As you can see, use of an extension for purposes of language extension
is almost completely explicit. I like this design.
Co-extension : sampler-linear sublanguage of GLSL <---branching
restriction coextension--- full WebGLSL
With the present design of restricting the semantics of the built-in
unannotated texture types, I do not support the exposure of the
branching restrictions as an extension. I believe that the use of a
coextension ("no branch restrictions enabled by default, disable to
enforce restrictions") makes more semantic sense in the context of the
existing GLSL extension system design.
Pros of the coextension approach:
1. No new type attributes
2. Can load both shaders that disable the extension ("enable the
coextension") and those that are silent (implementors may wish to
optimize for the former, though, by deferring analysis until it is
required by the loading of a secure resource or simply erroring when
the coextension is not used)
3. Authors can declare "this shader is universal" by "#extension all : disable"
4. Authors can query "in which contexts is this shader verboten?" by
"#extension all : warn"
Cons of the coextension approach:
1. Which samplers are restricted is implicit (or every sampler must be
2. Some shaders may not enable the coextension but still conform to
3. No precedent (afaik) but the Web is a new environment with (as we
now see) new restrictions
4. Existence implies that WebGLSL with non-linear sampler usage is an
implicit extension of a more basic language (true)
As you can see, use of a coextension for purposes of language
restriction is almost completely implicit. I can see the appeal of
this design (even in the dual implicit extension form) in changing as
little as possible between language modes; however, I'd rather
annotate each sampler than pretend like the old and new sampler types
are actually interchangeable.
There will definitely be more language restrictions like this in
future as the numerical core of GLSL moves into new contexts to share
libraries among processors and hosts. It makes sense to develop the
philosophy and theory of language extensions early (i.e. now) to avoid
warts and ugly hacks later ("what do you mean I have to enable an
extension to lose features?").
I would like to personally invite the members of the GLSL ES WG to
publicly participate in this discussion with concrete insights from
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: