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: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 14 Nov 2018 10:41:06 -0800
Message-id: <86C5FD5F-AFF7-49FD-863A-5E08A52AD665@apple.com>
Cc: Filip Pizlo <fpizlo@apple.com>, David Neto <dneto@google.com>, public-gpu <public-gpu@w3.org>
To: Corentin Wallez <cwallez@google.com>

> 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 <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.

I respectfully disagree. Language semantics can either enable security or not. It’s not just an external property. Those semantics need to be specified and checked against the desired security properties. That’s especially so when interoperability is required.

Imagine if someone proposed a “Secure C++” and specified it as “implement C++, but make sure no use-after-free or out-of-bounds memory access happens”. That is not a useful specification for a secure and interoperable language. The added security properties are at odds with the nature of the underlying language

From my perspective, that’s exactly what you are doing here. The result will be either terrible interop, or  “standard” that in practice can be used only by using one specific shared implementation.

> 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.

That document describes semantics, not just implementation.

We can’t leave the semantics of how to achieve security to a non-normative implementation note.

The rest of the web platform specifies how to achieve secure semantics. For example, an important security property of the web is that a webpage from one site can’t read arbitrary content from another site that was loaded with the use of any user-specific credentials. But the spec doesn’t stop at saying “do whatever, but make sure this doesn’t happen”.  The behavior of many features, including Canvas, Fetch, XHR, the omg and video elements, and so forth, is specifically designed  to achieve these properties.

That’s the level of detail you need to achieve security an interoperability at web scale.


Received on Wednesday, 14 November 2018 18:41:36 UTC

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