- From: Corentin Wallez <cwallez@google.com>
- Date: Wed, 14 Nov 2018 17:42:10 +0100
- To: fpizlo@apple.com
- Cc: Maciej Stachowiak <mjs@apple.com>, David Neto <dneto@google.com>, public-gpu <public-gpu@w3.org>
- Message-ID: <CAGdfWNOhv5kSkzUprJG+Em=kqV6bs5ik0oKH9+O_YdZ1rqw1wQ@mail.gmail.com>
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