<Venemo>
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
<Venemo>
mslusarz: feel free to ping me when you open a MR, I can help review the nir parts at least
kts has quit [Quit: Konversation terminated!]
junaid has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
fxkamd has joined #dri-devel
<Venemo>
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"?
<mslusarz>
Venemo: I'll take a closer look on Monday
godvino has joined #dri-devel
jaganteki has quit [Remote host closed the connection]
godvino has quit [Read error: Connection reset by peer]
junaid has joined #dri-devel
godvino has joined #dri-devel
srslypascal is now known as Guest9599
srslypascal has joined #dri-devel
godvino has quit [Read error: Connection reset by peer]
godvino has joined #dri-devel
Guest9599 has quit [Ping timeout: 480 seconds]
smilessh has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
godvino has quit [Read error: Connection reset by peer]
cheako_ has quit []
cheako has joined #dri-devel
fxkamd has quit []
godvino has joined #dri-devel
godvino has quit [Quit: WeeChat 3.6]
srslypascal has quit [Quit: Leaving]
srslypascal has joined #dri-devel
bgs has joined #dri-devel
CHIMPOUT has joined #dri-devel
CHIMPOUT has left #dri-devel [#dri-devel]
imre has quit [Quit: leaving]
Guest9532 is now known as imre
ifreund_ is now known as ifreund
luc4 has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
i509vcb has joined #dri-devel
Haaninjo has joined #dri-devel
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
cphealy has quit [Quit: Leaving]
Zopolis4_ has joined #dri-devel
<DemiMarie>
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?
<HdkR>
Vulkan API can't be considered secure. Applications could just ship their own and talk directly to a device. Needs to be kernel uapi
<HdkR>
Also some hardware enforcement of mapped memory so you can't leak data of course
JohnnyonFlame has joined #dri-devel
Guest9590 is now known as lumag
<DemiMarie>
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.
JohnnyonF has quit [Ping timeout: 480 seconds]
<HdkR>
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
<DemiMarie>
Which API?
<HdkR>
kernel uapi
<DemiMarie>
Oh indeed. I meant as part of a defense in depth strategy.
<DemiMarie>
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.
<HdkR>
Security in the Vulkan API doesn't really make sense. Someone doing something nefarious can just sidestep it
<HdkR>
and will just sidestep it
<DemiMarie>
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)
<DemiMarie>
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.
<DemiMarie>
(except by sandboxing the GPU process)
<DemiMarie>
s/of Venus/of WebGPU/ duh
<HdkR>
Web is a bit of a special case I guess
<HdkR>
Luckily there isn't a WebVulkan yet
<DemiMarie>
That is what WebGPU is
<HdkR>
hah
<DemiMarie>
“hah”?
<HdkR>
I guess web is saved that it can't just call ioctl :)
<DemiMarie>
Same for Venus and VirGL
<HdkR>
You can ioctl the venus and virgl virtual devices though, so that needs to be robust
<DemiMarie>
Oh yeah
<HdkR>
Since it goes through virtgpu
chipxxx has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #dri-devel
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #dri-devel
gouchi has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
danilo has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
lemonzest has quit [Quit: WeeChat 3.6]
<robclark>
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
<robclark>
(plus, I wouldn't really want to rely on shader compiler as a security boundary)
chipxxx has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
chipxxx has joined #dri-devel
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
chipxxx has quit []
<DemiMarie>
robclark: Indeed the kernel uabi is unquestionably a security boundary. My question was if there were any in the userspace stack.
shoragan has quit [Quit: quit]
shoragan has joined #dri-devel
iive has quit [Quit: They came for me...]
pcercuei has quit [Quit: dodo]
junaid has joined #dri-devel
DUOLabs[m] has joined #dri-devel
junaid has quit [Remote host closed the connection]
anholt has joined #dri-devel
<jenatali>
DUO Labs: You're not authed with NickServ so your messages didn't make it to IRC
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<DUOLabs[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.