Re: Shader security model discussions: breaking it down?

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