Re: draft execution environment for WebGPU, including WebGPU env spec for SPIR-V

> On Nov 14, 2018, at 8:42 AM, Corentin Wallez <cwallez@google.com> wrote:
> 
> 
> On Wed, Nov 14, 2018 at 5:29 PM Filip Pizlo <fpizlo@apple.com <mailto:fpizlo@apple.com>> wrote:
> 
> 
> On Nov 14, 2018, at 8:12 AM, Corentin Wallez <cwallez@google.com <mailto:cwallez@google.com>> wrote:
> 
>> On Wed, Nov 14, 2018 at 5:10 PM Filip Pizlo <fpizlo@apple.com <mailto:fpizlo@apple.com>> wrote:
>> 
>> 
>> On Nov 14, 2018, at 4:44 AM, Corentin Wallez <cwallez@google.com <mailto:cwallez@google.com>> wrote:
>> 
>>> To steal David's words, being secure is a property of the implementation and not a property of the language. The language can just influences how hard it is to make secure. The security properties outlined in that section would need to be implemented both for whatever language we choose. For example array clamping/trapping on OpAccessChain needs to happen the same way it needs to happen for WHLSL array refs.
>> 
>> That document doesn’t appear to even mention OpAccessChain. 
>> 
>> I think that for this document to match the level of detail that we have in WHLSL, it would need to specify semantics for OpAccessChain in case of OOB. I don’t think we want a spec that says “implementation will make this secure by doing whatever it likes”. 
>> 
>> I respectfully disagree, the spec should focus on defining what secure means and not how it is implemented. If you want to see the implementation details you should read #33 SPIR-V Robust Resource Access <https://github.com/gpuweb/gpuweb/issues/33> as mentioned above and numerous times before.
> 
> I’m not asking it to say how it is implemented. I’m asking that it says enough about semantics that developers targeting WebGPU know what behavior they are going to get and implementors of WebGPU can validate that they implemented something that conforms. 
> 
> I thought the group had agreed on something along the lines of the robust resource behavior described in #33 <https://github.com/gpuweb/gpuweb/issues/33> plus potentially trapping.

Perhaps, but I don’t think we agreed that it would be underspecified.  I’d like whatever language we use here to have some minimally-ambiguous description of what happens on important operations like loading and indexing.  We should only allow ambiguity when we need it for perf, and then we should do it by enumerating the permitted outcomes (trapping, clamping, returning zero, whatever).

> If you feel we should focus on providing a definition of this in that repo, feel free to open an issue.
>  
> You need to be particularly specific with something like OpAccessChain. There needs to be some verbiage that says: if the index is in bounds then this happens, else one of these things happens. Just saying that something will happen so long as it’s secure doesn’t cut it. 
> 
> That section is meant to not be SPIR-V specific and basically says that all memory accesses follow the robust resource behavior described. We could have a non-normative section about what SPIR-V operations are memory accesses. An issue would help prioritize it too ;)

I don’t think that would be enough.  The other web language specs (JS, wasm) have a semantics for what happens on every operation.  We should do that here, too.  That’s what we’re going for with WHLSL.

-Filip


>  
> You guys often argue that GLSL was a bad experience and then blame it on the fact that it was text. It seems that you learned the wrong lesson. GLSL gave people a bad time because it was underspecified. Let’s not make the mistake of using another underspecified format, this time SPIR-V. 
> 
> -Filip
> 
> 
>>  
>> -Filip
>> 
>> 
>>> 
>>> Specifications are not supposed to contain implementation details, or only in non-normative sections. We don't specify how to achieve security because that's an implementation detail. That said we described how the implementation of SPIR-V can be made secure more than a year ago in #33 SPIR-V Robust Resource Access <https://github.com/gpuweb/gpuweb/issues/33> and most of the implementation details would be similar in WHLSL (trapping behavior was brought up only after we posted that issue). This investigation shows that an implementation of SPIR-V can be made secure, and that robust resource access being possible is orthogonal to the execution environment.
>>> 
>>> Cheers,
>>> 
>>> Corentin
>>> 
>>> On Wed, Nov 14, 2018 at 12:06 AM Maciej Stachowiak <mjs@apple.com <mailto:mjs@apple.com>> wrote:
>>> 
>>> This document describes what security properties are desired In the "General WebGPU Environment” section, which is great. But it doesn’t appear to describe how a SPIR-V dialect can achieve these properties in the "WebGPU Execution Environment Specification for SPIR-V”, not even as TBDs as far as I can tell.
>>> 
>>> Is it it intentional that how to achieve security is unspecified?
>>> 
>>> Regards,
>>> Maciej
>>> 
>>>> On Nov 13, 2018, at 1:41 PM, David Neto <dneto@google.com <mailto:dneto@google.com>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> In a recent meeting Google promised to produce a draft WebGPU environment spec for SPIR-V. 
>>>> 
>>>> Today we created a new GitHub repo for all documents related to SPIR-V use in WebGPU.  It has a first draft of the promised environment spec.  Please see https://github.com/gpuweb/spirv-execution-env/blob/master/execution-env.md <https://github.com/gpuweb/spirv-execution-env/blob/master/execution-env.md>
>>>> 
>>>> In writing the draft we realized there were considerations on how WebGPU would execute shaders, independent of shader language. So the document is split in to several parts: A general part that always would apply, and a part that is a WebGPU environment spec for SPIR-V.
>>>> 
>>>> Many items are marked "TBD", and most of them will be resolved once the community group determines exactly what features are supported by WebGPU.
>>>> 
>>>> This is ready for initial review and discussion by the community group.
>>>> 
>>>> thanks,
>>>> david