Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Taste of WebGPU in Firefox

hacks.mozilla.org

Post reply on HN
Print view View original

31–40 of 80 posts

Re: A Taste of WebGPU in Firefox

#31

Post by MaxBarraclough »

JoshTriplett wrote: post #26
MaxBarraclough wrote: post #23

Earlier quoted context omitted.

The browser should simply disable WebGPU by default. It's already intended to be sandboxed, but given what happened with WebGL, I'm not convinced we can trust it. There's nothing to gain by faking a GPU. Edit For clarity, I'm saying you may as well just disable WebGPU. A CPU-based simulated GPU would indeed improve security, but its performance would be so atrocious that there would be no point having it compared to…

> There's nothing to gain by faking a GPU. Moving applications that can do anything into sandboxed pages in a browser that can't do arbitrary things to the user's system is a win. The more capable the browser is, the more things that once would have been downloaded applications can become safely sandboxed pages.

As I said, it's already intended to be sandboxed for security. As I've clarified in an edit, my point was that CPU-based virtual GPUs perform so poorly that they aren't worth implementing.

Re: A Taste of WebGPU in Firefox

#32

Post by ddevault »

MaxBarraclough wrote: post #2

Will this API be opt-in, or can we expect another security disaster like with WebGL? https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/en/blog/webgl-a-new-dimension-for-... , https://www.contextis.com/en/blog/webgl-more-webgl-security-... Edit I should have given a quote from one of the articles covering the issue, so here's one: > anyone running Firefox 4 with WebGL support is vulnerable to h…

The web is an ever growing rube goldberg machine of security vunlerabilities. The web is impossible to secure and the web will never be secure. Only browse sites that you trust, with JavaScript disabled and adblocking enabled, and hope that they haven't been compromised. This is the best you can do in the face of the reckless behavior of browser vendors.

Re: A Taste of WebGPU in Firefox

#33

Post by MaxBarraclough »

gmueckl wrote: post #15

So this WebGPU stuff is pretty much a Javascript binding to Vulkan. The design is almost 1:1 identical. Good luck securing that! I find bugs in the standard Vulkan validation layer pretty regularly after it has been in development for a couple of years. Sure, some of the stuff is pretty hard to check like device memory addresses. But just this week I had the validation layer blow up spectacularly because I simply dar…

I'm not following your final point. What does it matter if Vulkan gives you more runtime checks than you were expecting?

Re: A Taste of WebGPU in Firefox

#34

Post by _jal »

vasco wrote: post #28
JulienSchmidt wrote: post #22

Earlier quoted context omitted.

I feel like this should require the user's explicit permission, just like audio, camera, location or Flash and Java Applets at the end of their life. WebGPU is a great innovation, but we have both privacy and security concerns here. It should be available where and when the user wants it, not silently in the background.

Why don't you say the same about CPU or RAM? In the end it's just resources that are abstracted away to the user, used with the purpose of performing tasks in the most efficient way possible.

Because some resources have mature security controls around them, and some don't.

Why do you care if someone can see your bank account number? In the end they're just numbers.

Re: A Taste of WebGPU in Firefox

#35

Post by notyourday »

MaxBarraclough wrote: post #29
notyourday wrote: post #25

Earlier quoted context omitted.

There is - it is a GPU with all the bells and whistles but even if the browser's security context is broken, the browser cannot access anything on a real desktop.

It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues. A CPU-based fake GPU is guaranteed to have performance so poor that it isn't worth doing. This is the reason modern graphics APIs don't make provisions for CPU-based implementations. If we aren't confident in the security of the WebGPU imp…

> It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues.

That was my mistake - i was not clear. I'm talking about virtualized GPUs that can be passed to a VM running a minimum system needed to boot a browser.

Re: A Taste of WebGPU in Firefox

#36

Post by MaxBarraclough »

notyourday wrote: post #35
MaxBarraclough wrote: post #29

Earlier quoted context omitted.

It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues. A CPU-based fake GPU is guaranteed to have performance so poor that it isn't worth doing. This is the reason modern graphics APIs don't make provisions for CPU-based implementations. If we aren't confident in the security of the WebGPU imp…

> It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues. That was my mistake - i was not clear. I'm talking about virtualized GPUs that can be passed to a VM running a minimum system needed to boot a browser.

Ok, so you're suggesting always running the browser in a VM, and using the GPU from within the VM (via the host OS of course).

I believe significant work has been done on the browser/graphics sandboxing problem. Whether browsers use techniques comparable to virtualisation, I don't know. I'm afraid I don't know much about how that's done, or how effectively virtualisation is able to contain the operations of VMs, or how high the performance penalty is.

Going with guesswork though, it seems to me virtualisation doesn't offer particularly solid guarantees here. If the host OS has a buggy graphics driver, it would presumably be possible for it to leak data back to the VM. Any facilities the GPU can offer to help contain semi-trusted graphics contexts, should presumably be available for use directly by the browsers, without running a guest OS in virtualisation.

Re: A Taste of WebGPU in Firefox

#37

Post by gmueckl »

MaxBarraclough wrote: post #33
gmueckl wrote: post #15

So this WebGPU stuff is pretty much a Javascript binding to Vulkan. The design is almost 1:1 identical. Good luck securing that! I find bugs in the standard Vulkan validation layer pretty regularly after it has been in development for a couple of years. Sure, some of the stuff is pretty hard to check like device memory addresses. But just this week I had the validation layer blow up spectacularly because I simply dar…

I'm not following your final point. What does it matter if Vulkan gives you more runtime checks than you were expecting?

The loader is a backdoor to load arbitrary code as long as it is disguised as a Vulkan layer (a specialized shared library). It is intended for debugging, but a layer can hook the API to do anything it wants.

Re: A Taste of WebGPU in Firefox

#38

Post by banachtarski »

gmueckl wrote: post #15

So this WebGPU stuff is pretty much a Javascript binding to Vulkan. The design is almost 1:1 identical. Good luck securing that! I find bugs in the standard Vulkan validation layer pretty regularly after it has been in development for a couple of years. Sure, some of the stuff is pretty hard to check like device memory addresses. But just this week I had the validation layer blow up spectacularly because I simply dar…

Stop propagating misinformation. Personally, I wish WebGPU had gone a slightly different way (thanks Apple :/) but it's definitely no way 1:1 identical with Vulkan.

Also your last point makes no sense. That's been the state of desktop graphics programming for years and years. You really don't control much as IHVs are always free to intercept calls and control things at the driver level.

Re: A Taste of WebGPU in Firefox

#39

Post by fulafel »

MaxBarraclough wrote: post #2

Will this API be opt-in, or can we expect another security disaster like with WebGL? https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/en/blog/webgl-a-new-dimension-for-... , https://www.contextis.com/en/blog/webgl-more-webgl-security-... Edit I should have given a quote from one of the articles covering the issue, so here's one: > anyone running Firefox 4 with WebGL support is vulnerable to h…

A lot of other web APIs and features had rce vulnerable implementations in stable browser releases when they were new, some worse than others. Eg webaudio, SVG, etc. Not an excuse of course but tells of the cross cutting systemic problems.

Re: A Taste of WebGPU in Firefox

#40

Post by banachtarski »

gmueckl wrote: post #37
MaxBarraclough wrote: post #33

Earlier quoted context omitted.

I'm not following your final point. What does it matter if Vulkan gives you more runtime checks than you were expecting?

The loader is a backdoor to load arbitrary code as long as it is disguised as a Vulkan layer (a specialized shared library). It is intended for debugging, but a layer can hook the API to do anything it wants.

Give me one example of a graphics API today on desktop where this isn't possible. Unless you're a console graphics engineer, you're shit out of luck if you really think you can stop client-side injection. Short of a kernel-mode injection like the crap Valorant is pulling, layer hooks and trampolines are literally how those APIs ship (D3D, OpenGL, Vulkan, etc).
Post reply on HN