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

On Thu, Aug 17, 2017 at 5:08 AM Stephen White <steve@adam.com.au> wrote:

> On 17 Aug 2017, at 4:47 am, David Neto <dneto@google.com> wrote:
> >     - If the implementation trusts the shader and safety is not required
> at this level of the implementation, then you elide the checks in both
> cases.  E.g. do this if the implemention delegates safety guarantees to a
> more general level of protection, e.g. MMU hardware and its OS support
>
> Could we have a bit more of a look at this? If buffers and memory regions
> are unmapped before running the WebGPU context, then security could be
> reduced to monitoring binding and context rather than per call bounds
> checking?
>
> --
>   steve@adam.com.au
>
>
Strictly speaking this is an implementation detail.

The *specification* should be minimally prescriptive about behaviour: e.g.
that out-of-bounds accesses result in (for example) shutdown of the
application without other side effects.
It's up to the implementation to determine how best to achieve that.  The
spec doesn't talk about MMUs, for example.

Of course, hopefully the spec is written with common and efficient
protection mechanisms in mind, so that it's practical to implement.  So,
for example, it's useful for graphic specs to have buffers and images as
first-class objects that are individually allocated and separately bound to
shaders.  Then a common implementation technique would be that, at runtime,
the binding carries with it address bounds, and the hardware implementing
that binding access point will automatically and cheaply do the bounds
check without needing to modify the shader.

Just to be clear: for the web the attitude should be that the shader is
untrusted.


cheers,
david