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

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

This is certainly true, but I do agree that such checks would be done prior
to shader dispatch, outside of the shader code.

On Wed, Aug 16, 2017 at 6:50 PM Maciej Stachowiak <mjs@apple.com> wrote:

> 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> wrote:
>
>>
>> On Aug 16, 2017, at 4:39 PM, Dean Jackson <dino@apple.com> wrote:
>>
>>
>>
>> On 17 Aug 2017, at 05:08, Maciej Stachowiak <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>.
>> 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?
>>
>>
>>