00:19DemiMarie: Thoughts on all the vulns found by H26Forge?
00:41alyssa: zmike: when will we be able to run lavapipe on zink
00:41alyssa: for vulkan on vulkan layering
00:42alyssa: looking forward for the benchmarks comparing lavapipe-on-zink to venus
00:49zmike:swats alyssa
00:49zmike: bad
01:01alyssa: >:)
14:56mslusarz: Venemo: sort of related to MR 22222, I'm considering submitting this soon: https://gitlab.freedesktop.org/mslusarz/mesa/-/commits/mesh-wgs (either 5 or 7 commits, I'm not sure yet, because I get weird perf numbers)
14:59Venemo: mslusarz: I'll take a look
15:03Venemo: mslusarz: interesting, I think I can use that too on AMD GFX10.3, though won't be needed once I have time to do the full implementation for GFX11
15:03Venemo: mslusarz: feel free to ping me when you open a MR, I can help review the nir parts at least
15:30Venemo: mslusarz: so, speaking of 22222 do you think it would be better to add a "uint32_t mesh_dispatch_dimensions[3]" field instead of "bool linear_dispatch"?
15:34mslusarz: Venemo: I'll take a closer look on Monday
19:54DemiMarie: What is the most easily secured layer of the graphics stack? Is it the Vulkan API layer, the kernel UAPI layer, or some sort of mediated passthrough?
19:56HdkR: Vulkan API can't be considered secure. Applications could just ship their own and talk directly to a device. Needs to be kernel uapi
19:59HdkR: Also some hardware enforcement of mapped memory so you can't leak data of course
20:02DemiMarie: HdkR: in the use-cases I am thinking of, applications *cannot* talk directly to a device, because the device is in a different virtual machine.
20:03HdkR: Even with something like virgl or venus you could still feed invalid data through it, so your API needs to be robust against that regardless
20:05DemiMarie: Which API?
20:05HdkR: kernel uapi
20:06DemiMarie: Oh indeed. I meant as part of a defense in depth strategy.
20:06DemiMarie: Also the AMD drivers at least have a known vuln (infoleak) in the kernel UAPI, which I presume will be fixed when native context support is added.
20:08HdkR: Security in the Vulkan API doesn't really make sense. Someone doing something nefarious can just sidestep it
20:08HdkR: and will just sidestep it
20:08DemiMarie: On Xen, for instance, one could run virgl or venus in the isolated stubdomain that provides device emulation services, while the stubdomain itself uses virtio-GPU native contexts to talk to the GPU (which might itself be a SR-IOV virtual function)
20:09DemiMarie: HdkR: in e.g. WebGPU or Venus, the attacker cannot sidestep it. In the case of Venus, for example, is the browser’s responsibility to conform to valid Vulkan API usage, but the browser can’t reasonably be expected guard against a malicious shader that exploits a use-after-free in the NIR optimizer to gain code execution.
20:09DemiMarie: (except by sandboxing the GPU process)
20:10DemiMarie: s/of Venus/of WebGPU/ duh
20:10HdkR: Web is a bit of a special case I guess
20:11HdkR: Luckily there isn't a WebVulkan yet
20:11DemiMarie: That is what WebGPU is
20:12HdkR: hah
20:14DemiMarie: “hah”?
20:14HdkR: I guess web is saved that it can't just call ioctl :)
20:15DemiMarie: Same for Venus and VirGL
20:15HdkR: You can ioctl the venus and virgl virtual devices though, so that needs to be robust
20:15DemiMarie: Oh yeah
20:16HdkR: Since it goes through virtgpu
21:49robclark: DemiMarie: kernel uabi needs to be sound.. if there are bugs, they need to be fixed.. api virtualization won't really save you when the api (cl and to some extent vk) gives shaders access to pointers
21:52robclark: (plus, I wouldn't really want to rely on shader compiler as a security boundary)
22:43DemiMarie: robclark: Indeed the kernel uabi is unquestionably a security boundary. My question was if there were any in the userspace stack.
23:35jenatali: DUO Labs: You're not authed with NickServ so your messages didn't make it to IRC
23:55DUOLabs[m]: Ok should work now: Does anyone have any experience working with the internals of the Venus driver? I want to know where does Venus outputs its textures to. I keep seeing references to udmabuf, but that can't be true, as it wouldn't be installed on most user's machines.