Re: Shader security model discussions: breaking it down?

On Wed, Aug 23, 2017 at 9:22 PM 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.
>>
>>  by the Application*.

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.
>>
>
You're absolutely right. I should have done another pass to clarify this.
Yes, by program I meant "Application." By application I include all of the
untrusted code we receive from the webpage, including JS, WASM, shaders. So
"values produced" includes data that the application puts into GPU memory
via buffers, uniforms, textures, etc.

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?*
>
> Good questions, bolding these to add them into the shortlist(s) of
questions at the end of this discussion.


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

AFAIK inlinability is not one of the constraints that we've been
considering.

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 is a good topic to

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

"all (...) target platforms" is an intentionally ambiguous phrasing. Our
set of target platforms is not yet known. But I think it can be assumed to
include "most" D3D12, Metal, and Vulkan platforms.

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

Yes, I certainly think there is consensus here.


> 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.
>>
>
Yes. These security constraints apply to the entire API usage, both inside
and outside shaders.

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.
>>
>
Thanks. I would love to discuss these after we have made sure we're talking
about the right issues.

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

A *non-specced insecure mode* sounds practical to me. A good note to add to
this list item.

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

Great points.