[HN Gopher] WebGPU Technical Report
___________________________________________________________________
WebGPU Technical Report
Author : ibobev
Score : 189 points
Date : 2023-09-28 10:59 UTC (12 hours ago)
(HTM) web link (chromium.googlesource.com)
(TXT) w3m dump (chromium.googlesource.com)
| Anya200 wrote:
| [flagged]
| gregwebs wrote:
| I read the Android team is trying to secure Android by writing
| new code in Rust. I am wondering how many of these issues would
| go away by using Rust or at least minimized to easier to audit
| unsafe blocks. Obviously it might take them 10x the effort to
| write the code on Rust and to integrate that into Chrome, but the
| security effort shown here has a large cost as well.
| nvm0n2 wrote:
| Wouldn't help in this case, the bugs are in things that Rust's
| type system doesn't help you with like references being held
| across processes that are sharing memory segments, connected to
| GCd JavaScript heaps. Affine types aren't able to express that
| stuff.
| insanitybit wrote:
| At least some of the issues here appear to be UAFs where raw
| pointers are taken to RC'd objects under the assumption that
| the object will not be freed while the raw pointer is held.
| That is not possible to express in Rust (without unsafe).
|
| Some other issues are definitely going to be trickier - for
| example, passing a raw pointer to another context and then
| crashing that context while it's still held. This has come up
| within Rust before - how do you handle `&str` backed my mmap
| when another process could write to those values.
|
| And then some are... maybes. Integer underflow panics in
| tests but not in release - when mixing it with something
| inherently unsafe like alloca, would Rust have helped? IDK.
| Certainly I think integer overflows are less likely to make
| it to release in Rust thanks to the default behavior, but
| it's also absolutely an area where I expect Rust to do only a
| bit better than other languages.
| alexvitkov wrote:
| You're overthinking it. The rust argument often boils down
| to:
|
| Rust = Safety. Those things sound unsafe, therefore Rust
| solves them.
| Rusky wrote:
| Cross-process shared memory doesn't really make a difference
| here. Rust's support for multithreading works the same way
| regardless, there's no expressivity problem.
| insanitybit wrote:
| x-process shared memory is definitely a problem. This has
| come up before - ex: is it safe to hold a &str into an
| mmap'd page? Another process could modify the data such
| that it is no longer valid utf8, even though you held a
| reference to it.
|
| This is just out of scope for the borrow checker. Instead
| you'll have to roll your own abstraction that tries to
| maintain its own invariants, such as a &MmapStr that
| doesn't perform any `unsafe` operations that assume utf8/
| immutability.
| [deleted]
| wffurr wrote:
| Already happening but the timeline is too late for Dawn (the
| Chrome WebGPU implementation):
| https://security.googleblog.com/2023/01/supporting-use-of-ru...
| Cloudef wrote:
| Theres wgpu if you have hard on for rust webgpu implementation.
| Also zig implementation called dusk (very early)
| pjmlp wrote:
| Zig still has UAF problem.
| bionhoward wrote:
| Seems like the first two issues would be harder to encounter in
| rust (raw pointers and double mutable borrows) but rewriting a
| huge project is a bad idea because of the massive amount of
| work involved.
|
| The maintainers could make a crate for some tiny crucial
| vulnerable subsystem and call it from c++, that might be more
| reasonable baby step and get them rolling with rust inside
| chrome (as opposed to chrome inside rust which would possibly
| take forever, some dork can crank a little rust program in a
| weekend)
|
| Also automatic rewriting the whole codebase could work but
| that's just a research direction at this point even for google
| as far as I know, and chrome probably isn't the kind of thing
| you just auto-rewrite and it works right away (maybe I'm
| pessimistic)
| pjmlp wrote:
| Initially the Chrome team was the opinion that adding Rust to
| Chrome would be a too big effort and thus focusing on better
| practices for C++ would be a better approach, hence Olipan,
| the C++ GC now introduced in V8.
|
| Eventually about an year later they changed their mind, and
| are now allowing Rust for new code in Chrome, in a kind of
| baby steps.
|
| Most likely, because as the report shows, no matter how
| carefully the code is written and reviewed, there are
| security flaws due to memory corruption sneaking in.
| galangalalgol wrote:
| I think you are correct to suggest starting from small
| important pieces. I propose the attack surfaces and working
| out from them. The dom, and sandbox as a whole seems like a
| prime candidate.
| nicoburns wrote:
| There is at least already a WebGPU implementation in Rust
| (the one that Firefox uses). So they could use that if they
| wanted to. I guess it's probably better for the overall
| health of the ecosystem if there are multiple implementations
| though.
| coderedart wrote:
| Just wanted to point out that wgpu has both webgpu and
| webgl2 backends. So, currently, most projects use the
| webgl2 backend via wgpu for any rust app running in firefox
| right now.
| tormeh wrote:
| Yup, wgpu is already a thing. While it's ironically widely
| used on desktop, it's less mature in the browser context.
| Like, there is an open-world 3D MMORPG using wgpu for its
| graphics, meanwhile it's not yet enabled on stable Firefox.
|
| I'm not sure whether many different implementations is
| inherently good, though.
| nabakin wrote:
| What MMO?
| tormeh wrote:
| https://veloren.net/ I'm a bit impartial since I'm a
| former contributor, but I think it's super cool.
|
| Aside from that, the Bevy game engine also uses wgpu on
| non-web, but afaik no game of particular significance or
| player base has shipped with it yet. I think the biggest
| user of it is actually a software tool for mining (the
| hardhat kind), but it's a "call us for a quote" kind of
| thing so hard to tell how big it is.
| nabakin wrote:
| Veloren is an MMO? Thought it was just a multiplayer game
| i_am_a_peasant wrote:
| wgpu I think might be finally an OpenGL killer. It's more
| platform independent than any graphics API ever dreamt of
| being.
| pjmlp wrote:
| Middleware has existed since mid-1990's.
| fyrn_ wrote:
| That's true, but how many middleware were also available
| by default in the browser?
| pjmlp wrote:
| Plenty, using browser plugins back in the day, targeting
| ActiveX, Flash, PNaCL.
|
| Additionally wgpu and WebGPU aren't the same thing, as
| wgpu exposes native features as well.
| i_am_a_peasant wrote:
| I think he means Veloren.
| cormacrelf wrote:
| You can say the same thing about something as simple as
| "shared memory" -- normal multiprocessing computers have
| had shared memory since time immemorial, but browsers
| literally disabled SharedArrayBuffer from 2018 to 2020
| and anyone using them to communicate with Web Workers had
| to find another way. Browsers run a 24/7 onslaught of
| extremely untrustworthy code, whereas games only run
| themselves.
|
| Firefox has not enabled WebGPU via wgpu for the same
| reasons Chrome Security has done an in-depth review of
| Dawn. It is a component that must be hardened. For anyone
| out there trying it out by enabling config flags,
| remember to disable it once you are done. It will be
| ready in time.
| josefx wrote:
| > whereas games only run themselves.
|
| Until you run multiplayer and are suddenly dealing with
| hostile players, servers and possible mods.
| cormacrelf wrote:
| I would love to hear about an implementation of
| multiplayer that receives code from hostile opponents and
| executes it, but I do not anticipate you'll find many
| examples.
| nolist_policy wrote:
| With the amount of visible bugs that every game is
| released with nowadays, there are easily as many security
| bugs.
|
| Depending on the game, it downloads maps, skins, etc.
| from the server... File parsing code is highly
| suspectible to security bugs.
| Buttons840 wrote:
| Ever heard of a game called "Call of Duty"?
|
| > SV_SteamAuthClient in various Activision Infinity Ward
| Call of Duty games before 2015-08-11 is missing a size
| check when reading authBlob data into a buffer, which
| allows one to execute code on the remote target machine
| when sending a steam authentication request. This affects
| Call of Duty: Modern Warfare 2, Call of Duty: Modern
| Warfare 3, Call of Duty: Ghosts, Call of Duty: Advanced
| Warfare, Call of Duty: Black Ops 1, and Call of Duty:
| Black Ops 2.
|
| https://cve.mitre.org/cgi-
| bin/cvename.cgi?name=CVE-2018-2081...
| cormacrelf wrote:
| In case this needs to be pointed out, an RCE in a game is
| an accident, not the way they designed their multiplayer
| to work. I was describing why the Firefox team might wait
| for a feature to be security-hardened before releasing
| it. The answer remains the same -- they design and market
| the thing to be secure even when it executes untrusted
| code. Activision does not advertise their games as able
| to "securely execute RCE gadgets from maliciously crafted
| steam authentication packets". This part may be
| surprising: the Chrome and Firefox teams _do, in fact,
| try to ensure that when someone gains RCE, that they
| execute it securely and it can 't get very far_.
|
| I am not attempting to claim that games do not have
| security issues or cannot experience remote code
| execution, just that this is not a normal pattern of
| behaviour that they plan for, so it is normal that a game
| author would deploy wgpu long before Firefox does (while
| Firefox spends a lot of effort on fuzzing, etc). If
| anything a terrible CVE that Activision has expended
| apparently zero resources fixing is a very good example
| of what I'm talking about.
| Buttons840 wrote:
| Understood. I should not have been snarky; I'm sorry. I
| think the CoD CVE is worth noting in this thread though.
| logicchains wrote:
| >Also automatic rewriting the whole codebase could work but
| that's just a research direction at this point even for
| google as far as I know, and chrome probably isn't the kind
| of thing you just auto-rewrite and it works right away (maybe
| I'm pessimistic)
|
| GPT4 is extremely good at translating between programming
| languages without error. The hard part is there's way to much
| code to feed to it all at once, so the naive approach of just
| feeding it all in wouldn't work, and doing it file-by-file
| would cause problems as GPT wouldn't understand the functions
| defined in other files.
| hutzlibu wrote:
| Even if you could feed ChatGPT4 with all of chromiums
| codebase, I really, really doubt it would just work.
|
| Otherwise it would be just a matter of scaling and waiting
| longer.
| kevingadd wrote:
| Not patching swiftshader bugs in swiftshader feels inexcusable
| and makes that whole component look like a huge security
| vulnerability. It's weird that this post mentions it multiple
| times but never explains why it's not getting fixed.
| jsnell wrote:
| Is it really true that those bugs aren't getting fixed? There's
| a commit on July 18th to SwiftShader that seems to be
| addressing exactly the bug described in this report:
|
| https://github.com/google/swiftshader/commit/4e401427f8dd799...
| nccgroupie wrote:
| An author of this report made that commit. It's good to see
| work like this.
| wffurr wrote:
| It's short-staffed and there's few community contributors. It's
| really unfortunate for a really foundational piece of
| infrastructure for Chrome, Android, and more.
___________________________________________________________________
(page generated 2023-09-28 23:00 UTC)