Re: RFC: Re: shader IR vs. application IR

> On Aug 16, 2017, at 6:27 PM, Kai Ninomiya <kainino@google.com> wrote:
> 
> WebAssembly's IR doesn't (and can't possibly) guarantee memory safety on its own. It relies on the execution environment (WebAssembly VM in this case) to provide these guarantees - but a WebAssembly VM could exist which omits memory safety checks.

In a sense, safe or not is ultimately a property of the implementation. However, as I understand it the WebAssembly specification explicitly mandates safety checks. A WebAssembly VM without memory safety checks would be nonconforming.

(Again, for total clarity, I'm not advocating WebAssembly as a shader language. Just citing it as an example of an IR with memory safety baked in by design.)

> Based on my non-expert understanding of WebAssembly, this is how it handles some of the example issues you gave:
> 
> > Any exposure of pointer values
> > Pointer arithmetic
> > Read or write to any location without bounds checks
> > Ability to read or write another process's main or video memory
> > Ability to read or write another shader's main or video memory
> > Ability to read or write video memory that holds the contents of a webpage, even one that is same-origin with the shader
> 
> Prevented by either (a) bounds checks (against the size of global memory) in the AOT/JIT generated native code, or (b) by CPU MMU control.
> (In a shader, of course, each resource would have its own bounds check sizes. So bounds constants probably can't be baked into the AOT/JIT generated code.)
> 
> > Ability to hold a pointer or reference to an object after it may have been freed, and still perform access through it
> > Potential for race conditions which may lead to access to out-of-bounds, freed, reallocated or not-yet-freed memory
> 
> Heap allocations do not exist at the IR level (except for "request global memory expansion"). malloc and free are implemented inside the wasm program.
> Shaders do not allow "heap"/"global memory" allocations (and I don't think SPIR-V provides a way to do them).

Shaders are able to access resources provided by the surrounding program/environment, though, and for safety must avoid use-after-free against those resources. Maybe this is down to the API's memory model not the shader language per se.

> 
> > Function call or jump to an arbitrary addresses (jumping to known functions or labels is ok)
> > Mixing dynamically indexed data structures, and function pointers or executable code in the same memory space
> 
> WebAssembly instructions are not stored in program-accessible memory. Jumps are only possible to known functions and labels. Both seem to be true of SPIR-V as well.
> 
> > Ability to execute an infinite loop without ever being interrupted by a watchdog or the like
> 
> Just like a JS infinite loop, the process can be killed or the VM can generate cooperatively-terminable code. For WebGL, a watchdog is typically used.
> 
> -Kai
> 
> On Wed, Aug 16, 2017 at 5:24 PM Maciej Stachowiak <mjs@apple.com <mailto:mjs@apple.com>> wrote:
> 
>> On Aug 16, 2017, at 4:39 PM, Dean Jackson <dino@apple.com <mailto:dino@apple.com>> wrote:
>> 
>> 
>> 
>>> On 17 Aug 2017, at 05:08, Maciej Stachowiak <mjs@apple.com <mailto:mjs@apple.com>> wrote:
>>> 
>>> But bolting on security is not impossible; as you point out, it's been done for GLSL.
>> 
>> Restricting GLSL for security wasn't particularly difficult. It doesn't have pointers, for example. This is another argument for a language that is slightly higher than an IR: It probably will be easier to secure.
> 
> I'm not totally sure that's true. WebAssembly is an example of an IR that has memory safety designed in. A colleague pointed out to me that WebAssembly also takes a very hard stance on limiting nondeterminism: <https://github.com/WebAssembly/design/blob/master/Nondeterminism.md <https://github.com/WebAssembly/design/blob/master/Nondeterminism.md>>. This is in contrast with SPIR-V where many things are undefined.
> 
> To be clear, I am *not* saying WebAssembly should be the shader format. I think it's probably not appropriate, because its memory safety depends in part on limiting the whole WebAssembly program to a single contiguous memory region. To the best of my understanding, that would not really work for shaders. I'm just citing it as an example of a binary IR language that meets web safety requirements, because it was designed with them in mind.
> 
> Java bytecode is arguably another IR designed for memory safety, though the complexity of their strategy for achieving it made Java not actually very web safe in practice.
> 
>  - Maciej
> 
>> For the SPIR-V folks, has any implementation actually used Logical Addressing Mode? I'd also like to understand what these proposed restrictions to SPIR-V mean for compute shaders. How are they impacted by Logical Addressing Mode?
>