WebGPU Technical Report
chromium.googlesource.com
chromium.googlesource.com
https://github.com/google/swiftshader/commit/4e401427f8dd799...
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)
I'm not sure whether many different implementations is inherently good, though.
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.
Additionally wgpu and WebGPU aren't the same thing, as wgpu exposes native features as well.
Those examples you gave are not comparable at all, ativex and flash are way, way higher level, don't operate at all like graphics API middleware. PNaCL was a WASM alternative design, which thankfully lost as WASM is much more flexible.
My point is that WebGPU is way better positioned than any middleware, it has industry backing and official support from all relevant platforms (or plans for it). It's also benefitted a huge amount from hindsight.
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.
Until you run multiplayer and are suddenly dealing with hostile players, servers and possible mods.
> 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...
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.
Depending on the game, it downloads maps, skins, etc. from the server... File parsing code is highly suspectible to security bugs.
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.
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.
Otherwise it would be just a matter of scaling and waiting longer.
Rust = Safety. Those things sound unsafe, therefore Rust solves them.
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.
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.
The point of Rust's type system here is that it makes that distinction at all, not that the one side of that distinction has additional invariants.
No you can't, not without unsafe. Rust will not let you.
Again, this is sort of an up in the air discussion. In most cases saying "your type system can't handle someone else ptrace'ing you" is obvious and fine, but when you're talking about certain abstractions like mmap, where multi-processing and shared contexts are inherent, it's important to note that you can't just rely on normal aliasing rules.
Outside of a pure-Rust single-threaded process that uses only stack allocation, those cases are already using unsafe- for heap allocation, or to launch a thread, or whatever. Or if Rust is a guest in some other language's process, you don't even need unsafe! And the type system features used to contain that unsafe are just as useful when you're sharing memory with another process as when you're sharing memory with another thread.
I'm obviously not saying you can just take a shared reference to an arbitrary mmapped buffer, or whatever. I'm saying that nvm0n2's claim is misleading, because Rust's type system does give you the tools for cases like this, at least to a greater degree than C++'s type system!