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:12:11 +0100
Message-ID: <CAGdfWNPLjt3UL6tNBPm4e8=wtwYKx5wBE0u=ODBZhBeOcyvNdg@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: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.

> -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:12:47 UTC

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