> 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 <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?
Received on Thursday, 17 August 2017 00:23:38 UTC