Comment by gmueckl | Hacker News Reader

Comment by gmueckl | Hacker News Reader

Parent Full thread

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.

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...

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).

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.

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.

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.

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).

Reply on news.ycombinator.com