GPU Spectre/Meltdown

FYI:

> There have also been questions about GPU architectures. AMD Radeon GPU
architectures do not use speculative execution and thus are not susceptible
to these threats.
[https://www.amd.com/en/corporate/speculative-execution]

> We believe our GPU hardware is immune to the reported security issue. As
for our driver software, we are providing updates to help mitigate the CPU
security issue.
[http://nvidia.custhelp.com/app/answers/detail/a_id/4611]
[
https://techcrunch.com/2018/01/10/nvidia-ceo-clarifies-its-gpus-are-absolutely-immune-to-meltdown-and-spectre/
]

On Wed, Jan 17, 2018 at 10:41 AM Corentin Wallez <cwallez@google.com> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *GPU Web 2018-01-10Chair: CorentinScribe: KenLocation: Google
> HangoutMinutes from last meeting
> <https://docs.google.com/document/d/1wG9BRLUSw4FbpnvqieK--jTWaNnuaahtA0VBIvHdA5c>TL;DR
> - Specter/Meltdown does it affect Web GPU APIs?- GPU APIs are less at risk
> because by nature GPUs go wide in shader instances and not deep with
> speculative execution.- Should 1) ensure that GPU drivers are as safe as
> possible 2) watch what responses are on the CPU side- Shading languages
> Google’s position document <https://github.com/gpuweb/gpuweb/issues/44>-
> Consensus to take ownership of the high-level language and pipeline to
> bytecode (if needed).- Concern that ingesting SPIR-V is not easier than
> ingesting HLSL- Action item to detail in an email- Concern that this
> position doesn’t address online compilation well. There would be a blessed
> “JS/WASM” HLSL->SPIRV compiler, why not ship it in the browser?- Would have
> inconsistent versions between browsers- Consensus to try to go with SPIR-V
> at the API level and the HLSL->SPIR-V compiler inside or outside the
> browser. Discuss more when we have more experience.Tentative agenda -
> Specter/Meltdown interactions- Shading languages- Agenda for next
> meetingAttendance - Apple- Dean Jackson- Myles C. Maxfield- Google -
> Corentin Wallez- David Neto- James Darpinian- John Kessenich- Kai Ninomiya-
> Ken Russell- Microsoft- Ben Constable- Chas Boyd- Rafael Cintron- Mozilla-
> Dzmitry Malyshau- Jeff Gilbert- Markus Siglreithmaier- Yandex- Kirill
> DmitrenkoRecap of status update - Google: - started prototyping inside
> Unreal Engine to see how NXT might work- More work on Vulkan backend- put
> together proposal for SPIR-V- No updates from Apple or Microsoft-
> Microsoft:- Reviewing official position papersSpectre/Meltdown interactions
> - MM: no specific agenda; what do people think about these topics?- Big
> security problems that have to do with speculative execution and caching-
> GPUs have timing facilities, memory and caches- Concern that some of these
> attacks can be launched via GPUs- Many different general pieces- This type
> of attack requires high-fidelity timing. Many ways of getting it. One way
> is explicitly; scheduling performance queries. Another way is with UAVs.-
> Say you draw a triangle that covers two pixels. One of the fragment shader
> invocations could write a 1, 2, … into the UAV. Other pixel could read that
> value from the UAV and use it to construct a high-res timer, then launch
> the attack.- Don’t want to disable UAVs because that would prevent a host
> of algorithms from running on this API.- So what’s the right solution? Any
> thoughts about this?- CW: UAVs allow counting time in a way like
> SharedArrayBuffers do. This is why SABs were disabled in browsers. However
> this disabling was temporary. Just disabling them while shielding browsers
> against these attacks.- Feels that in a way we might not have a problem
> with high-res timing. Need to shield against stuff that might use it.-
> Attacks use speculative execution. Think GPUs might not be doing this (at
> least as much).- But, WebGL’s thought about this in the context of DRM
> content.- JG: usage of resources you don’t have privilege to read back in
> WebGL – can think of it like speculative execution – executing with inputs
> you might not have access to read from.- Original defense was: disable
> readback from screen.- Was demonstrated via timing attacks that it’s
> possible to deduce the contents of GPU resources that were accessible to
> WebGL. This is why WebGL forbids access to cross-origin resources.- CW:
> should try to see if, on GPUs right now, there’s a way to do speculative
> execution.- Probably want to spend fewer resources on making a single
> instance go faster and more resources on width.- MM: Brought up this topic
> because specs last longer then HW.- Would be tricky if we couldn’t run
> webgpu on future devices because of the structure of this API.- BC: problem
> you’re talking about in the non-web context of these APIs. Probably will be
> work done in these spheres that we can lean on.- Like Windows just patched
> the CPU side, if MSFT finds a security issue, future HW will probably take
> it into account.- KR: We had internal discussion, NVIDIA published a new
> driver that’s supposed to guard against one of these attacks by better
> isolating stuff with the GPU MMU. There was concern about GPUs and UMA
> architectures but it was pointed that this architecture are dumber than
> CPUs and only allocate one page ahead. One these architecture there could
> be guard pages. Not trying to paper over the issues, but it seems GPU APIs
> are less at risk than others.- JG: one major difference with the more
> vulnerable APIs: we aren’t actually letting people run whatever code they
> want. If we want it to be vulnerable to speculative execution then we’d
> have to allow speculative execution in the API.- KR: The PoC Javascript
> code is running in a VM that does a bounds check upfront. The pb is that
> the CPU is running over the bounds check with speculative execution. GPU
> pipelines are built for width and not depth so seems likely to be hit.
> Potentially severe problem on GPUs too? Especially with compute shaders.
> Need to make sure at the driver, browser and API level we don’t allow for
> risky behavior.- CW: we think GPU APIs are slightly less at risk because of
> the nature of GPUs. But we should ensure (1) the GPU folks’ drivers be
> safer if they can be and (2) we should see what CPUs and browsers do in
> response to these attacks.- MM: mainly bringing this up as something we
> have to think about in the future.Shading languagesGoogle’s position
> document <https://github.com/gpuweb/gpuweb/issues/44> - CW: made a document
> with why we think the API should ingest SPIR-V.- Something we didn’t make
> clear: we still think it’s useful for the group to spec HLSL, or at least
> for the group to take ownership of the high-level to low-level pipeline
> (including the test suite), given that the API would ingest the low level.-
> We think we get the best of both worlds this way.- Want to solicit feedback
> in particular from Myles.- MM:- Apple thinks this is a good step in the
> right direction.- Glad Google has officially stated idea of blessing HLSL
> and taking ownership of *a* language.- Have some concerns about expecting
> every web site in the world to use the compiler we ask them to use.- CW:
> goal with the proposal: there’s an easy path with the compilers this group
> provides. But emphatically not intending to force everyone to use this
> compiler.- Leads us to a tricky situation: we now have gone from one API to
> three, if we’re expecting many people to make compilers. API of source
> language, API the compiler will emit, and the API the browser will accept.
> This makes the fragmentation problem worse, not better.- Think this doesn’t
> help with having one shader source run the same everywhere.- JG: ingesting
> SPIR-V means we have to take this in at the API level. Emitting SPIR-V from
> HLSL compiler means investing in that environment. (..)- JK: not running up
> against the portability issues of frontend compiler.- BC: statement from JK
> if you’re talking about offline compilation. Questions about online
> compilation. The source language ingestion becomes relevant.- KN:
> regardless of online or offline compiler, you’re running the same compiler
> and it runs deterministically.- JG: might be multiple HLSL compilers.- KN:
> idea is that you’d ship it- JG: ship it alongside the browser, possibly
> inside the browser- CW: just to clarify, Google is not proposing to ship
> the HLSL compiler in the browser- MM: generally feel online compilation is
> needed by many frameworks and we should solve it.- JG: you can do that with
> SPIR-V. SPIR-V is concatenatable.- BC: Cesium for example wants to do
> online compilation. Proposal as it stands, Cesium would bring in a JS
> version of an HLSL compiler, and that compiler would be available from the
> WebGPU WG, and then generate SPIR-V and put it into the API.- JG:
> counter-proposal is that you can use SPIR-V to snip together snippets.- MM:
> section 2.4 of SPIR-V defines ordering of various SPIR-V sections.- Type
> identifiers in one module won’t match those in another.- Don’t agree with
> the statement that they’re concatenatable.- JK: people have written tools
> to merge together SPIR-V modules. It’s simple.- CW: point with Cesium: they
> have an existing code base and it would be hard to redo by merging SPIR-V
> modules- KN: really don’t think Cesium would switch from GLSL to HLSL to
> switch which compiler they use. If they switch languages they probably
> would be able to switch to an offline compilation model. Existing content
> in GLSL (or HLSL): for that use case they would use a GLSL -> SPIR-V
> compiler.- BC: looking at Cesium as a pattern of development is more useful
> than as a specific customer. Porting from ES 3.0/ D3D11 API to D3D12 API is
> non-trivial exercise.- DJ: agree. Early on we said we want to ingest source
> language.- KN: don’t think it’s acceptable to force all existing WebGL
> frameworks to rewrite in HLSL or something else.- DJ: that’s not what I
> said. Apple would like the requirement to do online compilation from a
> source language.- CW: online compilation from a source language: Google’s
> suggestion is that there is a blessed WebAssembly / JS thing that “just
> works”.- DJ: that’s awesome. I then ask the question: why don’t we just
> include it in the browser? Wouldn’t have to do as much validation on the
> SPIR-V output of it. The compiler won’t be huge, we’re saying that pages
> can include it.- JD: there will be different versions, different bugs.
> Compatibility issues with different browsers.- DJ: we’re improving the
> compiler as we move it forward.- KN: if the app ships a buggy version of
> the compiler they can upgrade it when they want.- Moving a bug from the
> browser to the application means that they can fix it *if they want/need
> to*.- Otherwise applications can more easily break when they switch
> browsers, operating systems, etc.- SPIR-V interface is much smaller than an
> HLSL interface. It’s much easier to make sure we get that interaction
> correct.- DJ: this is another point we disagree with.- CB: Could be that
> for typical application that we’ve been talking about right now produces
> simple SPIR-V- Perhaps consuming “secure” SPIR-V at the high level will
> make it easier to validate- DJ: our experience with JavaScript,
> WebAssembly, image formats, binary formats on the web have shown the
> opposite. And Java proper.- JG: have you investigated writing a SPIR-V
> validator? It’s a month project max.- CB: looking at it.- MM: that’s our
> fundamental disagreement. Writing the SPIR-V validator and any sort of
> enforcement checks will be difficult enough that we disagree it’s faster or
> easier.- RC: what about SPIR-V is difficult? SPIR-V specifically? Binary
> vs. text? something else?- MM: one example: SPIR-V uses numeric identifiers
> for every operation. Every operation has to look up these identifiers
> inside the table, and need bounds checks. If you had an AST inside a text
> language you would just do the lookup.- JK: hard to believe that numbers
> are harder to deal with than names.- JG: wrote an assembler for this and
> just treat the numbers like abstract names. Use them for hash lookups.- CW:
> trying to understand why Apple thinks SPIR-V might not be easier to parse
> than the high level language.- CB: easier to track the security issues
> during parsing when dealing with the high-level language.- DJ: could we
> write this up and send it as an email?- CW: OK- DJ: vague suggestion: we’ve
> discussed this a lot and are consuming a lot of time. One way forward is to
> basically press pause and allow implementations to do one or the other or
> both. Get some implementation experience and developer feedback. Think
> we’re a fair way away from consensus. Think we’re far - KR: Encourage to
> look at the curated list of ANGLE compiler bugs. The bugs we encountered
> over the years aren’t because our code is crap, it is because of inherent
> properties of text languages. It is because we are using identifiers and
> text language for GLSL. SPIR-V eliminates all of these, the validation
> occurs at the low-level. If we include a compiler it will still make sense
> to say that the compiler will lower to SPIR-V and then validate that.
> Preprocessing in the browser is a disaster and we shouldn’t make the same
> mistake.- DJ: OK. I don’t think it changes my argument much. There were a
> lot of bugs dealing with GLSL. Don’t know whether you disagree- BC: maybe
> modifying what Ken said: if we can have an agreement that a high level
> language is needed for certain scenarios, and an intermediate language is
> useful for a certain set of things, maybe disagreement is where the code
> lives. If we can agree on what the high level language is that the group
> focuses on, and we can agree on an IL, then maybe we can reduce the
> discussion to “where does the HLSL -> IL compiler” go.- KN: agree that
> that’s one of the issues but think Apple’s disagreeing on a separate issue-
> BC: want to focus on where we have agreement. If we all agree that the
> lingua franca of WebGPU is a variant of HLSL and there is an API on the
> surface that takes SPIR-V then we can at least have a situation where
> implementations have the same API surface and take in the same source code.
> Can vary where different pieces live and where they operate. If we could
> all agree on this as a framework it would unlock a development.- DJ: think
> that this is a good suggestion- CW: agreeing (1) HLSL is the high-level
> language and we will shepherd it forward (2) the API will ingest SPIR-V (3)
> where the HLSL->SPIR-V compiler lives is still up in the air?- BC: yes.
> Want to ask: important to me that a WebGPU example / demo’s source code is
> not SPIR-V, it’s HLSL. Think we can make a good step forward on what we
> agree on.- MM: agree with everything Ben just said. Want clarification on
> point (2)- CW: (2) the API to ingest shaders is SPIR-V. Maybe something
> else too. Thought this was what Ben said.- BC: from the point of view of
> the JS signature for the WebGPU API, those entry points will take in SPIR-V
> in binary form. But the corresponding thing is that if you put up an
> example, the example will be written in HLSL. Everyone might have a
> different story for how the HLSL is compiled. Some people might have online
> or offline support. But we’d have commonality on SPIR-V production and
> ingestion, on the high-level language.- MM: paraphrasing: think we can
> agree on points (1) and (3) but not (2) -- don’t want the browser to ingest
> SPIR-V.- By agreeing on points (1) and (3) think we’re moving the
> conversation forward- BC: argument for point (2): lot of experience on the
> Apple side you’ve wanted to share on efficiency of binary vs. text, etc.
> Having Apple work in the SPIR-V space and gain experience would help
> convergence. Microsoft will have to do some work and learning in SPIR-V
> too. By trying it you might find it isn’t as bad as you thought.- MM: OK,
> we can definitely get experience ingesting SPIR-V. But we don’t want to
> agree that the final API will ingest SPIR-V.- BC: not trying to define the
> MVP API. Just commonality to agree on at this moment to move the discussion
> forward.- MM: sounds great. In addition, we will also work on a native HLSL
> -> native platform path that bypasses SPIR-V.- BC: sounds good, will surely
> not be throwaway work regardless.- DJ: as Myles as manager, I agree with
> this direction- JG: sounds good. One of the things that we asked: was it a
> good example for the initial tutorials to be HLSL based. That sounds fine
> to me. Pretty much every set of tutorial websites choose the abstraction
> level, including their own matrix library, etc. This would be the simplest
> way to explain to people how to use the WebGPU API. Do think though that if
> we are including a SPIR-V ingestion step, need to explain how the SPIR-V
> interface works.- BC: bundle that into the “what pieces go into the
> browser” question to be answered later.- JG: sounds like a good way to move
> forward.- CW: sounds good. Just concerned that we’re just delaying the
> question and we’re going to debate this again later.- BC: if we all go
> forward with this then we’ll have multiple groups of people working with
> the same framework of all of this, and the conversations won’t be going in
> circles. Folks who have issues with SPIR-V will run into and raise those
> issues. Can revisit this in a couple of months time. Better than talking in
> the abstract.- KN: agree that this is one way to produce data and
> experience on the problem. Want to point out that there’s still a vast
> source of data still to be tapped, which is the ISVs, who already have this
> experience. Want to make sure: if we agree on this, we might receive data
> from ISVs that makes us go in a different direction befor*
>