Re: Shader security model discussions: breaking it down?

What is the proposal then for running on Vulkan, where this is not
supported?

Are we expanding the scope of this API to include OpenCL workloads? That
seems like a huge step of scope creep beyond what we've discussed
previously.

On Aug 24, 2017 12:54 AM, "Kai Ninomiya" <kainino@google.com> wrote:

> It was discussed on the call today that logical addressing mode could be
> too restrictive for some applications. We did not determine whether it is
> or not; there is an action item to do research into real-world GPU compute
> applications (e.g. in MSL, CUDA, OpenCL) and how they use pointer
> addressing features so we can make an informed decision.
>
> On Wed, Aug 23, 2017 at 9:51 PM Jeff Gilbert <jgilbert@mozilla.com> wrote:
>
>> Where does the proposal of non-logical-addressing spirv come from? My
>> understanding is that Vulkan requires logical addressing only.
>>
>> On Aug 24, 2017 12:22 AM, "JF Bastien" <w3c@jfbastien.com> wrote:
>>
>>> On Wed, Aug 23, 2017 at 9:00 PM, Maciej Stachowiak <mjs@apple.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Aug 23, 2017, at 8:46 PM, Kai Ninomiya <kainino@google.com> wrote:
>>>>
>>>> As was mentioned in today's call, there may or may not be agreement on
>>>> what is required of our security model.
>>>>
>>>> As a first step I want to make sure agree on a *lower bound* on the
>>>> strictness of the security model before we go into debates about further
>>>> restrictions. My understanding:
>>>>
>>>> * Any memory or data access of any kind MUST NOT make data visible to
>>>> the Application other than (a) default values or (b) any data produced by
>>>> the program.
>>>>
>>>>
>>>> Can you define your terms a bit more? What specifically do "the
>>>> Application" and "the program" mean in this case? Do these terms refer to
>>>> the same thing? Do they refer to just the shader program or the combination
>>>> of all shader programs plus the webpage (or other CPU-level application)
>>>> invoking them?
>>>>
>>>> At first glance your point seemed clear, but then I thought about what
>>>> it means for textures. Clearly shaders should be allowed to access the
>>>> contents of textures provided to them. But are those either "default
>>>> values" or "values produced by the program"? It depends on what "program"
>>>> means.
>>>>
>>>
>>> I think you also want to define what functions are allowed to do:
>>>
>>>    - Can I read the executable code?
>>>    - Can I direct-call a function with mismatched argument count /
>>>    return count?
>>>    - Can I indirect-call a function with mismatched argument count /
>>>    return count?
>>>    - Can I imbalance the data stack (pop more than I've pushed)?
>>>    - Can I call arbitrary addresses, or overwrite a return address?
>>>    - Is recursion allowed, and is it bounded?
>>>
>>> IIUC most GPU programs have perfect call information when compiled, so I
>>> could theoretically inline everything? If our languages enforces this then
>>> we're significantly simplifying the problem.
>>>
>>> You also want to specify how calls into and out of WebGPU work.
>>> WebAssembly calls this interaction with the "embedder". For example, in a
>>> JavaScript embedding you can't use i64 in your interface. There currently
>>> aren't any races possible, but I think WebGPU has to put extra thought into
>>> this to avoid ToCToU headaches while minimizing copying.
>>>
>>>
>>> * This must be implementable in a performant way on all current,
>>>> existing target platforms. (Platform-specific optimizations like robustness
>>>> guarantees or page table controls optional.)
>>>>
>>>>
>>> What are "all" platforms? WebAssembly limits itself to a set of
>>> portable targets
>>> <https://github.com/WebAssembly/design/blob/master/Portability.md>.
>>> Others can implement WebAssembly but will suffer a mild performance loss.
>>>
>>>
>>> I think the lower bound needs to include the constraints for writing as
>>>> well, not just reading. I'd hope there is consensus on this, though I was
>>>> not on the call.
>>>>
>>>
>>> Yes, writing as well :)
>>>
>>>
>>>
>>>> Also, these constraints must hold for the combination of the shader
>>>> language and the API itself. Races between the CPU and the GPU must not
>>>> allow memory safety constraints to be violated.
>>>>
>>>>
>>>> Beyond that, I'd like to figure out how to break down the discussion
>>>> before moving forward. Example questions (but I don't want to discuss these
>>>> questions YET):
>>>>
>>>>
>>>> I am so tempted to answer these questions, but refraining for now.
>>>>
>>>>
>>>> * Do we want fully general pointer behavior, the SPIR-V restricted
>>>> pointer behavior mentioned today, logical addressing only, or something
>>>> else? What high-level language features, algorithms, and techniques might
>>>> require more flexibility?
>>>>
>>>>
>>>> * Is it possible to provide any kind of "fault" behavior? - e.g.,
>>>> termination of execution in such a way that IF outside data is accessed by
>>>> the Device, the Device is terminated before that data can become visible to
>>>> the Application. If it's possible, is it useful?
>>>>
>>>>
>>>> * Can our security model be "optional" for an insecure-mode, "native"
>>>> (C/C++) version of the API? (Useful for native platform portability as well
>>>> as apps with both native and web versions.)
>>>>
>>>>
>>> WebAssembly just says that such implementations are non-conforming. You
>>> can still do it, we don't have a trademark enforcing conformance. Keeps the
>>> spec simple.
>>>
>>>
>>> What other questions can we add to this list?
>>>>
>>>>
>>> More questions:
>>>
>>> *Fault ordering.* We discussed whether fault behavior should be
>>> guaranteed to happen in program order or not. Fil gave the example of
>>> WebAssembly where that's the case, but with multiple warps going I'm not
>>> sure it's reasonably feasible. I don't want us to explore feasibility now,
>>> just adding that question to the list, let's figure it out later.
>>>
>>> *Nondeterminism.* Another question is whether you want full determinism
>>> on corner cases or not. WebAssembly clamps it down substantially
>>> <https://github.com/WebAssembly/design/blob/master/Nondeterminism.md>.
>>> You might even choose to leave it implementation-defined what happens on an
>>> out of bounds memory access: an implementation could be allowed to
>>> terminate *or* wrap around. I'm not advocating either way, just adding
>>> more to the design space. You'll definitely want to figure out how to
>>> resolve races in the face of threads and SIMD (not mandate a single
>>> outcome, but have some memory model).
>>>
>>>