13:37Company: dj-death: on Mesa main (I wanted to test your fix) Vulkan gives me a critical warning via the debug messages about VK_ERROR_INCOMPATIBLE_DRIVER for hasvk
13:38Company: that should probably not happen?
13:39Company: is that aybe just because the load order is random (by inode) and this time after I installed it tried hasvk before icd?
13:40Company: still, I should probably not get a message about it?
13:40Company: good news is that the fix does indeed work
13:41dj-death: what do you mean by critical?
13:43dj-death: I'm not sure where that error value is returned from
13:43dj-death: but our driver should not expose that to the outside
13:43dj-death: it's just used internally for figuring out whether we can use a particular device with a driver
13:43Company: Vulkan has this debug prant infrastructure
13:44Company: and GTK prints criticals from it to stderr as GTK criticals
13:44dj-death: hasvk reports a lower version supported for Vulkan
13:45Company: so I'm sseeing it on stderr when starting GTK apps with the Vulkan renderer
13:47Company: https://paste.centos.org/view/a04dd400
13:47Company: fwiw, I've had similar issues with similar drivers before
13:47Company: panfrost vs v3dv on my rpi for example
13:52dj-death: Company: ah
13:53dj-death: Company: I think this is a side effect of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27166
13:53dj-death: I wasn't really sure about that change
13:56Company: might just need to silently fail instead of raising an error?
13:56Company: like it does 15 lines below?
13:57dj-death: yeah
13:59Company: want me to file it or are you gonna take care of it?
14:01dj-death: just wrong the MR
14:01dj-death: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27294
14:48dolphin: airlied, sima: Sent out drm-intel-fixes PR, just one Cc stable fix. Didn't get CI results for it, maybe to do with the fact that I did the first cherry pick and push just before Dave pulled drm-intel-next-fixes to drm-fixes, that confused DIM
17:49alanc: apparently someone got tired of waiting for a response to their Mesa bug reports and got CVE ids issued so that all the distros will start harrassing you for fixes
17:50alanc: https://seclists.org/fulldisclosure/2024/Jan/28
17:50alanc: https://seclists.org/fulldisclosure/2024/Jan/47
17:52jenatali: Oof
17:54alanc: I've just seen those two come through so far, but the initial report to xorg-security had 5 bugs in it, so there may be more coming:
17:54alanc: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9856
17:54alanc: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9857
17:54alanc: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9858
17:54alanc: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9859
17:54alanc: https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/242
17:58mattst88: were those issues marked in gitlab as security-related or anything?
18:09alanc: not that I see
18:12alanc: yeah, still coming in (looks like someone's going through the moderation queue backlog for that mailing list right now)
18:12alanc: https://seclists.org/fulldisclosure/2024/Jan/50
18:18alanc: https://seclists.org/fulldisclosure/2024/Jan/52
18:25alanc: it's not just mesa, this academic research project hit a whole bunch of FOSS projects (xedit, xfig, gtk, gdk-pixbuf, vim, etc.)
18:26airlied: again the stupidity of the cve allocation system is shown
18:30alanc: in theory the X.Org Foundation can sign up to be the CNA for anything hosted on freedesktop.org, and then all CVE requests are supposed to be routed to us - Curl & Postrgres recently did this after getting annoyed at other folks getting CVEs assigned for bugs they didn't think should have a CVE - time will tell if it works for them
18:31alanc: the Linux Foundation could do the same for the Linux kernel, but then it would have to claim that assigning CVE's is something they actually want to do
18:33alyssa: sketchy academic "study" DDoS's open source projects, more at 11 :-(
18:36pixelcluster: >NULL pointer dereference in __glXGetDrawableAttribute()
18:36pixelcluster: wat
18:36pixelcluster: pretty sure that code checks for null even, it's just that it might read past the end if you *checks notes* alter variables in gdb lol
18:38robmur01: "NULL pointer dereference: To reproduce, use GDB to set pointer to NULL"
18:38pixelcluster: (i guess if your machine sends X11 stuff over an actual network I can see the "corrupting packages" point but still meh)
18:39pixelcluster: s/package/packet, it's getting late
18:42alanc: if you have a setuid program that runs Mesa and connects to an X server you've modified to send bogus responses, you can have a bad time, but really making anything with privileges run Mesa (or as an X client at all) was the real mistake there
18:44pixelcluster: how bad of a time can you really have?
18:44pixelcluster: isn't this like, a read overflow, so you can't even write anything funny to the out-of-bounds memory
18:45pixelcluster: I guess possible denial of service is a security issue
18:48alanc: yeah, I was thinking of a write overflow, not a read overflow
18:48alanc: denial of service in this case seems silly - if your X server is not trusted, you're already screwed, since it has full access to your keyboard input and window contents
19:04pixelcluster: yeah good point
20:36alyssa: alanc: but can it install drivers without your permision?
20:36alanc: depends if your distro still runs Xorg as setuid root
20:38mattst88: I had people really upset with me when I disabled setuid for Xorg in Gentoo
20:38mattst88: they wouldn't believe that using systemd/elogind was going to be more secure than running Xorg as root
20:45karolherbst: mattst88: you mean those who start Xorg within .loginrc?
20:45mattst88: karolherbst: I mean people that log in on a VT and then `startx` :|
20:46karolherbst: yeah some do that via .loginrc :D
20:46CounterPillow: please, they all type startx manually because anything else is "soy shit"
20:47karolherbst: imagine your character is "only who can use the tty deserve to use linux"
21:25alyssa:types `s` manually to start sway
21:38robclark: alanc: probably _any_ mesa CVE should be rejected.. if your gl or vk driver is a security boundary, you are doing things wrong
21:50CounterPillow: what if it's for khr_robustness
21:54tleydxdy: the worse that happens is just your app got killed?
22:04CounterPillow: oh right, yeah
22:06robclark: yeah.. something that, for ex, let one process observe other processes memory.. that could be a CVE.. but also mesa is (at least mostly) not the right place to fix that
22:22alanc: something like https://blog.trailofbits.com/2024/01/16/leftoverlocals-listening-to-llm-responses-through-leaked-gpu-local-memory/ then?
22:24alanc: (in which "Mesa" appears exactly one time)
22:32alyssa: > LLM
22:32alyssa: found the problem
22:36robclark: alanc: that specifically was the reason for the "(at least mostly)" part.. but in that case, it is mesa cleaning up after itself so it isn't leaking it's own state
22:36robclark: as opposed to relying on mesa to not let the user do something like supply their own pgtables
22:46kisak: anyone happen to know if there's a list of supported AMD backends in llvm? I'm looking to sanity check if https://github.com/llvm/llvm-project/pull/78884 is sane to backport to llvm 15.0.7 at a user's request. I'm thinking no...
23:02kisak: okay, I guess I found something coherent at https://github.com/llvm/llvm-project/blob/release/15.x/clang/lib/Basic/Targets/AMDGPU.cpp#L184
23:33robclark: alanc: apparently those were only reserving CVE #s, not an assignment.. https://www.cve.org/CVERecord?id=CVE-2023-45919 .. (not sure if I understand the difference)
23:38pendingchaos: kisak: https://releases.llvm.org/15.0.0/docs/AMDGPUUsage.html#processors
23:39pendingchaos: I think that would match what's supported
23:39pendingchaos: there's also AMDGPU.td
23:40kisak: I ended up writing "remove 941 942 1150 1151 1200 1201" if I end up doing another llvm build
23:41kisak: (in my notes)