W3C home > Mailing lists > Public > public-gpu@w3.org > November 2018

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

From: Corentin Wallez <cwallez@google.com>
Date: Wed, 14 Nov 2018 17:42:10 +0100
Message-ID: <CAGdfWNOhv5kSkzUprJG+Em=kqV6bs5ik0oKH9+O_YdZ1rqw1wQ@mail.gmail.com>
To: fpizlo@apple.com
Cc: Maciej Stachowiak <mjs@apple.com>, David Neto <dneto@google.com>, public-gpu <public-gpu@w3.org>
On Wed, Nov 14, 2018 at 5:29 PM Filip Pizlo <fpizlo@apple.com> wrote:

>
>
> On Nov 14, 2018, at 8:12 AM, Corentin Wallez <cwallez@google.com> wrote:
>
> On Wed, Nov 14, 2018 at 5:10 PM Filip Pizlo <fpizlo@apple.com> wrote:
>
>>
>>
>> On Nov 14, 2018, at 4:44 AM, Corentin Wallez <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. 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 ;)


> 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> 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> 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
>>>
>>> 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
>>>
>>>
>>>
Received on Wednesday, 14 November 2018 16:42:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:25 UTC