Re: Shader security model discussions: breaking it down?

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