Re: Shader security model discussions: breaking it down?

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