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

11–20 of 80 posts

Re: A Taste of WebGPU in Firefox

#11

Post by MaxBarraclough »

ericflo wrote: post #4
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…

Whether or not the API is opt-in is orthogonal to its security hardening - this is a false dichotomy.

I'm not suggesting any false dichotomy, I'm trying to reason about the likely security consequences given what we saw with WebGL in Firefox: serious security flaws in its implementation, with the features enabled in the browser by default. See my links above, one of which summarises with anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their system.

My thoughts are along these lines:

    ┌────────────────────┬──────────────────────────┬──────────────────────────────┐
    │                    │  Secure implementation   │  Insecure implementation     │
    ├────────────────────┼──────────────────────────┼──────────────────────────────┤
    │ Opt-in             │  Minimal security impact │  Significant security impact │
    │ Enabled by default │  Minimal security impact │  Security disaster           │
    └────────────────────┴──────────────────────────┴──────────────────────────────┘

Re: A Taste of WebGPU in Firefox

#12

Post by AdmiralAsshat »

MaxBarraclough wrote: post #11
ericflo wrote: post #4

Earlier quoted context omitted.

Whether or not the API is opt-in is orthogonal to its security hardening - this is a false dichotomy.

I'm not suggesting any false dichotomy, I'm trying to reason about the likely security consequences given what we saw with WebGL in Firefox: serious security flaws in its implementation, with the features enabled in the browser by default. See my links above, one of which summarises with anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their…

First time I've seen a decent-looking ASCII table in an HN comment. Well-done!

Re: A Taste of WebGPU in Firefox

#13

Post by m_eiman »

jeswin wrote: post #9
ericflo wrote: post #4

Earlier quoted context omitted.

Whether or not the API is opt-in is orthogonal to its security hardening - this is a false dichotomy.

But that's not what parent was saying, I think. He was saying that WebGL not being opt-in was a security disaster; while saying nothing about the security hardening of the WebGL module itself. Even when a module is well tested, I'd like non-essential modules to be opt-in too.

I’d like Javascript to be opt-in. Turning it on by default was a mistake.

Re: A Taste of WebGPU in Firefox

#14

Post by MaxBarraclough »

AdmiralAsshat wrote: post #12
MaxBarraclough wrote: post #11

Earlier quoted context omitted.

I'm not suggesting any false dichotomy, I'm trying to reason about the likely security consequences given what we saw with WebGL in Firefox: serious security flaws in its implementation, with the features enabled in the browser by default. See my links above, one of which summarises with anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their…

First time I've seen a decent-looking ASCII table in an HN comment. Well-done!

Thanks, it's technically not an ASCII table, it's from the Unicode (single line) style of https://ozh.github.io/ascii-tables/

Re: A Taste of WebGPU in Firefox

#15

Post by gmueckl »

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 dared to give it an unrealistically high index for a vertex binding and the layer attempted to resize its internal state tracking array for vertex bindings to accomodate that.

Vulkan has another fun aspect to it: the application doesn't have full control over the layer loading mechanisms in the mandatory driver wrapper. A user's system can be configured to load arbitrary validation layers in various ways and the application cannot prevent any of that. It can only ask for more layers to be loaded. This is great for development, but it also means that browsers can't generally assume that the Vulkan API does what they think it does. There might be a little extra in there.

Re: A Taste of WebGPU in Firefox

#16

Post by enos_feedler »

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…

Is this unique to Vulkan or would the same hold true for DX12 or Metal? If it’s unique, perhaps WebGPU could steer Vulkan closer to the others in this regard. I don’t think WebGPU is meant to be a Vulkan binding exactly but pushing secure and safe low level GPU computing across platforms. If Vulkan isn’t good enough implementation layer it will just need to evolve

Re: A Taste of WebGPU in Firefox

#17

Post by kvark »

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…

This isn't JS to Vulkan. You are talking about the Obsidian proposal [1] that was not accepted or implemented.

WebGPU is higher level. High enough to hide the most nasty aspects of Vulkan, yet low enough to still extract the performance benefits of a proper API.

Implementing validation and proper input sanitation is undoubtedly a big challenge. Each browser engine(!) vendor is going to be tackling that separately. We are ready to learn on Vulkan mistakes and drive this story of validation and CTS to be better. One of the things that make a difference in comparison to Vulkan is that validation is not an afterthought, not a side developer assistance tooling. Validation is in the core of WebGPU, it's mandatory and always enabled, so chances are it will be more polished.

[1] https://github.com/kvark/WebGLNext-Proposals/blob/obsidian/O...

Re: A Taste of WebGPU in Firefox

#18

Post by gmueckl »

enos_feedler wrote: post #16
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…

Is this unique to Vulkan or would the same hold true for DX12 or Metal? If it’s unique, perhaps WebGPU could steer Vulkan closer to the others in this regard. I don’t think WebGPU is meant to be a Vulkan binding exactly but pushing secure and safe low level GPU computing across platforms. If Vulkan isn’t good enough implementation layer it will just need to evolve

Vulkan itself is what it is now: an abstraction of (reasonably) modern GPUs on a very low level. It is certainly very useful in that it allows applications to use GPUs in ways that are very efficient and simply impossible with older APIs, especially OpenGL. The flipside is that this flexibility and the intentional thinness of the abstraction makes it hard and actually undesirable to check the validity of the API usage in actual production use. That's why the debug layer is an optional layer and not part if the Vulkan loader.

I need to check out a few things, but if WebGPU prevents access to a few hairy bits of Vulkan like explicit synchronization and memory management (the Vulkan app has to provide that), it might be securable. There are still some benefits over OpenGL left like the entire pipeline state being expressed in pipeline objects.

I don't know about DX12 or Metal in practice, so I will not comment on that.

Re: A Taste of WebGPU in Firefox

#19

Post by kangz »

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…

WebGPU is extremely different from Vulkan. They have similar concepts because they're both from the same family of "explicit APIs" (that also contains Metal and D3D12).

Vulkan is hard to validate because it was designed assuming it trusts the developers to follow the valid usage rules. For example it is the developer's responsibility to only destroy GPU resources after they are done being used. Validation layers have to track for each submission the link from vkCmdBindDescriptorSets to descriptor sets to texture views to textures just to validate there is no use after frees, and that's just one of the many many valid usage rules.

In contrast a guiding principle in the design of WebGPU is that it should be fully validated at a reasonable cost. Keeping the same example, calling texture.destroy() in WebGPU will make the browser destroy the texture after all previous execution completes, and prevents any further usage of that texture. The Web Platform Tests (WPT) is a test suite that ensures browsers are interoperable. WebGPU's tests in WPT will contain test cases for all validation rules and corner cases, including overflows like the one you mentioned (and check it produces an error that is handled gracefully).

Re: A Taste of WebGPU in Firefox

#20

Post by flohofwoe »

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…

From the programmer's POV the API model is really more like Metal with a few bits and pieces "inspired by" Vulkan, but that doesn't even matter much for security considerations.

I don't think any of the existing implementations just "passes through" any "request" to the underlying 3D APIs (which is not just Vulkan btw) without taking it apart, looking at each piece to make sure it checks out, and then reassembling it. The security implications shouldn't be much different than WebGL (for better or worse of course).

The philosophy of the modern 3D-APIs like Metal, Vulkan and D3D12 of doing all costly configuration operations upfront instead of during rendering should help a lot to improve rendering performance compared to WebGL, where those security validations literally happen at random times during rendering.

Post reply on HN