Re: Shader security model discussions: breaking it down?

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

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

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.

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.)
> 
> What other questions can we add to this list?
> 
> -Kai