Re: Shader security model discussions: breaking it down?

Good points, I may have misinterpreted the discussion on the call. I will
let someone else (Myles?) explain and correct what I said if needed.

-Kai

On Wed, Aug 23, 2017, 11:05 PM Jeff Gilbert <jgilbert@mozilla.com> wrote:

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