- From: Corentin Wallez <cwallez@google.com>
- Date: Mon, 16 Oct 2017 15:34:42 -0400
- To: public-gpu <public-gpu@w3.org>
- Message-ID: <CAGdfWNMX4Cg0RR01ceUx3YnNHpOJqdMm+pyaCDWkvP46CHKpYA@mail.gmail.com>
GPU Web 2017-10-11
Chair: Corentin Wallez
Scribe: Ken Russell
Location: Google Hangout
Minutes from last meeting
<https://docs.google.com/document/d/1XysTJ2jnvq1PpsSVJFLbOgbzKo9E21zlDe9FjloweXk>
TL;DR
-
Status update
-
Apple: migrating WSL to HLSL syntax, still writing SPIR-V codegen.
-
Google: posted document <https://github.com/gpuweb/gpuweb/issues/33>
about SPIR-V robust resource access.
-
Mozilla: progress on OpenGL and D3D12 bakend of grfx-rs-ll
-
Robust resource acces in SPIR-V
-
No prior art in WebGL because it doesn’t have compute level features
-
Discussion that robust resource access isn’t enough for security,
formal proof would be better.
-
Consensus that formal proof isn’t needed for MVP but a detailed
investigation is needed (AI: Google). A formal proof might be
required for
v1.
-
Formally proving SPIR-V security will prove security of a lot of
high-level languages.
-
Idea is that code transforms for security will live in the “shader
translator”
-
What security for shaders means
-
Security includes robust resource access, what else?
-
UBs could be specified like robust buffer access, as a undefined
among several choices. float4 v; v[4]; could return 0, 1 or any
element of
v.
-
WASM uses trap semantics efficiently where invalid accesses trap and
halt execution.
-
How to do this efficiently in vertex / compute shaders?
-
What about side effects like UAV writes?
-
Discussion whether to force all implementation to be have the same
for common UB cases like v[4].
-
Next steps to agree on shading languages?
-
Define security + audit proposed language
-
Language has to be portable, define portability constraints for
misbehaving programs.
-
Still no consensus on high-level vs intermediate-level.
Tentative agenda
-
Administrative stuff (if any)
-
Individual design and prototype status
-
Shading languages
-
Agenda for next meeting
Attendance
-
Apple
-
Dean Jackson
-
Myles C. Maxfield
-
Google
-
Corentin Wallez
-
David Neto
-
John Kessenich
-
Kai Ninomiya
-
Ken Russell
-
Microsoft
-
Ben Constable
-
Chas Boyd
-
Rafael Cintron
-
Mozilla
-
Dzmitry Malyshau
-
Jeff Gilbert
-
Yandex
-
Kirill Dmitrenko
-
ZSpace
-
Doug Twilleager
-
Elviss Strazdiņš
-
Joshua Groves
-
Tyler Larson
Administrative items
-
CW: TPAC meeting with WASM tentatively Tuesday 7th of Nov.
-
AI: Send it by email once we have confirmation
-
KR: Do we need to register for this?
-
DJ: Can ask W3C if we need to register just for a 1h meeting.
-
MM: suggests meeting in coffee shop otherwise. :)
-
DJ: Really really really close to getting an agreement on the W3C CLA.
Should have a resolution VERY soon.
Individual design and prototype status
-
Apple
-
MM: have written about half of the SPIR-V codegen phase of the
WSL/HLSL secure language (and are migrating it to HLSL syntax)
-
CW: will be great to see!
-
MM: working with Microsoft to have HLSL secure have some of the best
parts of WSL, to have something that’s backward compatible with lots of
shaders, and have useful features for people writing GPU software
-
As soon as writing codegen, will go other direction: ingest SPIR-V,
write out HLSL Secure
-
CW: using extended features?
-
MM: answering that question is the goal of the project.
-
Google
-
CW: making document about how to guarantee robust resource access in
SPIR-V
-
Posted to Github; hope people can look at it
-
With small API-side validation (e.g. buffers big enough for “sized”
portion of data), then can make somewhat simple SPIR-V
transforms to ensure
all pointer accesses are in-bounds of resources
-
Only one tricky case requiring fat pointers. Should probably be
rarely hit.
-
Have prototype pass and a prototype test; need to put them together.
-
DJ: will we talk about this document more in the actual meeting?
-
CW: can do.
-
KN: working again on compiling dEQP to Emscripten.
-
dEQP includes Vulkan conformance tests. So if we had some Vulkan
shim for WebGPU, we could plausibly run parts of the Vulkan
conformance
tests.
-
CW: could also plausibly write new WebGPU tests in the dEQP
harness.
-
Microsoft
-
RC: no status updates; working through legal stuff (HLSL -> W3C).
-
Mozilla
-
DM: solid progress on OpenGL backend for gfx-rs
-
D3D12: better subpass support; generating HLSL code from SPIR-V
-
Better mapping for descriptor heaps
-
Refactored way image views work to match Vulkan’s semantics
-
RC: how are you making D3D12 consume SPIR-V?
-
https://github.com/KhronosGroup/SPIRV-Cross
-
Use SPIRV-cross and go through the descriptor set bindings. Every
even descriptor set contains views; odd ones, samplers.
Shading languagesRobust Resource Access in SPIR-V
<https://github.com/gpuweb/gpuweb/issues/33>
-
CW: Out-of-bounds accesses are defined.
-
SPIR-V logical addressing mode adds a lot of useful constraints
-
Document describes how to ensure that newly-created pointers end up
within the resource
-
OpAccessChain creates new pointers; indices used in the new access chain
have to be ensured to be in bounds
-
Can just generate code to clamp indices. Structures have compile-time
size known.
-
Only difficulty: D3D12 read-write access buffer. (Any size, access
any way you want)
-
SPIR-V: this functionality exposed via unsized arrays at the end of
your shader’s resources.
-
For this case: query the size of the array (doable in SPIR-V), and
maybe make a fat pointer if needed. Look up the size of the array in the
fat pointer and clamp it.
-
Some validation on API side: if you have a structure that’s e.g. 40
bytes, make sure that the buffer you bind to it is >= 40 bytes.
-
Wouldn’t need that if you actually have robust buffer access in the
hardware. But on hardware that doesn’t support it, have this option.
-
JG: sounds similar to what we have to do in WebGL.
-
CW: actually don’t have to do this in WebGL yet, because we don’t have
shader storage buffers yet.
-
JG: we have to check the sizes of buffers bound for draw calls, clamp
array indexing, …
-
DJ: is this just the start of securing SPIR-V?
-
CW: no, this is basically the most difficult part. Clamping image
texel accesses is the only other case and is a lot easier. Only
constraint
there is that images must be minimum 1x1 size.
-
Reason we’re asking: taking an existing language and bolting on the
secure properties afterward. Apple has had the idea that the language
should be secure by design.
-
JK: most of the work is on the API side to make sure the resources
are big enough.
-
CW: you’ll have to clamp image texel accesses; have to clamp access
into constant sized arrays; and unsized arrays (SSBOs), where you have to
clamp. The language “secure by design” has to do all of these things.
-
MM: clearly clamping buffer and texture accesses to ranges are
necessary. But these aren’t sufficient for a secure language. A cursory
read of the SPIR-V spec turns up other things. OpPhi doesn’t require each
incoming block be represented in its operand list, for example.
Would need
to check these other constraints.
-
JG: please add these to a document
-
MM: not trying to point out a few ways to pwn SPIR-V. We’d have to go
through it operation by operation to make sure you can’t do something
you’re not supposed to do.
-
DJ: with WSL we’re thinking of using a formal proof system. To be
confident we can use SPIR-V we may not need to go to that level, but we
should go through it operation-by-operation
-
JG: what makes this different from how we secured WebGL?
-
DN: we haven’t defined the unit of containment. Have to say something
is secure *with respect to* something. Operation-by-operation is maybe
irrelevant if undefined behavior means “nothing can come from
outside this
virtual machine box”. May not need something more fine-grained than that.
-
MM: agree. Have to define what security means.
-
JG: sounds a lot like the reasoning for writing a new language is
that you’d have to fully understand an existing current
language. Throwing
the baby out with the bath water.
-
CW: think the argument is more that you can write a formal proof more
easily for a high-level langauge.
-
JG: in going through SPIR-V I think it’d be possible to prove it
secure
-
JK: there are fewer primitives in SPIR-V. Easier to prove things
about it than a higher-level language.
-
KN: my intuition as well is that it’d be easier to prove for the
lower-level languages.
-
JG: is proving the IR safe a hard requirement?
-
MM: no, not a hard requirement
-
DN: lots of GLSL implementations out there. A big gap between a
high-level langauge like GLSL and a low-level language like SPIR-V. Less
semantic content in the low-level language. Easier to reason about the
low-level language.
-
JK: you want this to be well-defined in real life, not just on paper.
-
DJ: with a cursory examination we found gaps in this low-level and
presumably easy-to-validate low-level language.
-
CW: think it’s needed for V1, but that a proof is too much to require
-
MM: think the language chosen for MVP should be the one we go with in
the long run. Analysis doesn’t have to require a formal proof
but does need
to be thorough.
-
CW: agreed. The robust buffer access investigation is half the story.
In addition to this, need to state the security guarantees for
WebGPU. Once
we have agreement, Google can go through the SPIR-V spec and address all
the problems. Assert that SPIR-V is almost secure, if not already
completely secure. And that trivial additions to the execution
environments
would make it completely secure.
-
DJ: sounds good. Would like to say that HLSL is also in the same boat.
-
JG: if it’s a closed compilation to compile any HLSL to SPIR-V, then
we only have to prove SPIR-V secure.
-
JK: right. We get a whole bunch of high level languages for free if
we demonstrate SPIR-V secure.
-
KR: The case with OpPhi not using all the arguments seems like a
problem that should be caught at validation time. We can take the SPIR-V
spec and add validation for things that would be malformed.
-
MM: agree, think there are a lot of SPIR-V programs compatible with
the spec that are illegal.
-
KR: SPIR-V is supposed to be well structured and an IL that a lot of
HL languages can target. If there are gaps in the SPIR-V spec let’s spot
them and fix them.
-
AI: for people who have found gaps in the SPIR-V spec, please post
them somewhere.
-
AI for Google: go through the SPIR-V spec and look at what would be
gaps and how they would be addressed.
-
DM: what are plans for SPIR-V security? Part of SPIR-V cross?
-
DN: have a branch of spirv-tools adding a transform which does the
OpAccessChain clamping. Have working code. Has the analysis for the
structured case. Assumes you have existing API-side validation.
-
CW: idea is that there’s an “ANGLE-Next” library that everyone uses
to implement WebGPU, and there’s a shared library in it implementing the
translator. In it is the transformer.
-
DM: understand where it goes. Wondering specific implementation plans.
-
CW: depends on a lot of things. DM: ok for now.
What We Mean by Security for shaders
-
CW: We’ve discussed what we mean by robust resource access. But what do
we mean by the rest of “security”?
-
JG: what are the outstanding questions? A lot of this comes down from
the web standards.
-
CW: what Myles talked about before is undefined behavior in the SPIR-V
spec that could lead to...whatever...because it’s undefined.
-
DJ: SPIR-V code must not be able to get through the ANGLE-Next
validation and (due to some inconsistencies in the spec, whatever) get past
robust buffer access.
-
CW: a shader that passes validation means that it doesn’t have undefined
behavior up to threading / locking / atomics / etc.?
-
DJ: behavior is within some boundaries of undefined access
-
MM: valuable to be able to have a branch instead of a clamp. If you have
a branch then you can hoist that above other checks.
-
JG: this sounds like an implementation detail
-
CW: Myles is saying that there shouldn’t be undefined behavior outside
robust buffer access-style choices of what happens.
-
JG: there may be cases where it’s not strictly specified behavior but is
“safe”.
-
DJ: we should reduce the number of situations where things aren’t
undefined.
-
CW: you can access float4 with integer indices. What about v[4]?
-
Should return something inside, or 0, or 1.
-
These should be specified. Just like robust buffer access.
-
KD: suggest a difference between defined and implementation-defined
behavior.
-
MM: one technique that led to speedups in WebAssembly and JS is a trap.
If something bad happens the program will just end immediately. In JS, the
program will tier down to a lower level of optimization.
-
In shaders, the entry point of the vertex/fragment shader would write
zeros to all outputs and return immediately. Have really great
performance
benefits. Wouldn’t have to do checks everywhere.
-
CW: there’s no “discard” in vertex shaders. If you trap very deeply
inside a call stack, how do you return to the main entry point and unwind
everything?
-
MM: you can unwind everything.
-
CB: does anyone have a call stack in their implementations today?
-
JG: do you mean in the shader implementation? No.
-
CW: assume there’s a program counter and function calls. Everything
needs to be inlineable. Compute APIs can do recursion however. GPUs have
support for real program counters. If we trap inside a deep call
stack then
as soon as a function returns we need to say “if (trap) {return;}” after
every function call.
-
JG: an interesting experiment potentially. If you tickle
under-defined behavior, maybe leave open to the realm of possibility
“return something from the buffer, or 1, or 0” abandon the
shader execution.
-
KN: with this vertex shader example, does it matter that you don’t
execute the rest of the program? What if you just set a “trap” bit?
-
CW: there are SSBO writes.
-
KN: right. So second point: regardless of that, what do you want to
do with SSBO writes? Those that occurred before the trap didn’t happen?
-
MM: writes before the trap are visible, writes afterward aren’t
visible.
-
DN: what’s the point of that if it’s an illegal program?
-
JK: you might want to say “some of the writes before the trap are
visible”
-
MM: why? If the implementation inlines everything why can’t we say
this?
-
CW: GPUs don’t work this way. If you inline everything you can easily
have giant programs.
-
MM: trying to invoke the “as-if” clause in some specs. Not proposing
we actually do it this way.
-
DN: the memory / storage model does not require serial stores.
-
MM: if there’s a return inside the loop the optimization would be
illegal.
-
JG / CW: would be disabling optimizations.
-
DN: what’s the benefit of getting these invalid writes if the
program’s illegal?
-
MM: goal’s to reduce non-portable programs.
-
DN: so you want to make every implementation execute the same way?
-
MM: understand it’s not possible in every case. But want to reduce
the scenarios.
-
JK: should invalid programs produce the same results everywhere?
-
MM: let’s define invalid. vec[4] should have consistent semantics.
-
JK: if you enforce everyone to implement the same way.
-
CW: if you spec it this way you prevent valid platform-dependent
optimizations. Some might implement the clamping with “& 3”. Some others
might do it differently.
-
JG: is what you’re proposing that rejecting shaders and writing zeros
would be an option? Or required if something goes wrong?
-
MM: we don’t have a strong opinion about the answer to that question.
But portability is really important. We already reduce performance for
security. Question isn’t that you’re making things slower to improve
portability. The question is what’s the tradeoff.
-
KD: that’s a security, not portability, issue.
-
MM: you can have a language that has a corner case that’s
un-portable, but nobody hits it. For simple cases, it’s totally feasible
-
KR: the same techniques that work to secure CPU programs will not
work on GPUs. GPUs work very differently. No traps, etc.
-
CW: please take this discussion to the mailing list.
What are the next steps so we can agree on the shading language
-
Open discussion points, arguments, etc.?
-
DN: define security. Audit whatever proposed language against it.
-
CW: be portable to the three APIs is another.
-
DM: want to know what the portability constraints for misbehaving
programs are.
-
DJ: hopefully we do agree that we want to maximize portability as much
as possible without sacrificing performance.
-
DJ: There’s still the open request from Apple and Microsoft that we have
a human-readable shading language.
-
Google and Mozilla expressed at the F2F that a low-level language is
good enough.
-
No consensus yet.
Action items
-
Google: look into SPIR-V security
-
JG: maybe hard to collaborate, but willing to work on analyzing
SPIR-V opcodes
-
Apple: describe the trapping behavior in shaders they proposed
-
Apple: post existing issues found in SPIR-V
-
CW: to start threads on human-readable vs. binary, high-level vs.
low-level
-
CW: email about TPAC
Agenda for next meeting
-
Not shading languages
-
Last week, didn’t get to use cases for synchronization.
-
DM: let’s discuss this
-
Memory barriers again?
-
JG: we can take a shot at it
-
MM: still learning Vulkan; will try to understand enough to
contribute if that’s on the agenda
-
How much portability / how much undefined behavior?
-
KR: someone posted ~7 WebGL GLSL bugs recently and found undefined
behavior even in the clamp() intrinsic. Can’t get away from it :)
Received on Monday, 16 October 2017 19:35:30 UTC