13:37 beritwoman: You sound like i have not contributed any sanity, scala compiler can be lifted to proper method for modern computing, i already showed the algorithm, it accesses two elements, predessor and successor, since on increasing set determines that sucessor is certain coefficent at least larger than successor, there is no loop needed, but you need btiwise two tact fast pot division, if one does not have bitwise can be emulated with lower paradigm i already
13:39 beritwoman: dwfreed brags how he discriminates me and proper sanity, be he michigan technology uni professor, but he is just a terrorist, and just like all others drags me into your initiated war, but he is going to lose it for sure.
13:46 beritwoman: it's not much hard work, but only some testing is needed, cause in scala for instance likely only one file needs to be changed to do the magic.
13:46 beritwoman: both of the under the hood algorithms and all methods were already offered, since i am under tap anyhow, i contributed it to you all.
13:48 beritwoman: i can also contribute the whole solution, but you have to promise me that you at least try to detach my sole and guilt from terror from me bringing some offtopic to the channel at times as exchange.
17:08 karolherbst: guess there is a second reason to dlopen LLVM now: supply chain attacks ala xz... apparently systemd already moved to dlopening dependencies, so they are only loaded when actually needed...
17:09 IceySnow: Hello, I need an assist with an issue I encountered after building and installing mesa from source.
17:25 pac85: karolherbst: does loading llvm really make a difference if nothing that uses it is loaded? It wouldn't be exposed by anything in that case right?. In fact AFAIK libraries are loaded lazily so until they are actually called into they aren't even available in the address space
17:25 karolherbst: pac85: yes, because that was the situation with ssh + xz
17:26 karolherbst: xz got loaded through libsystemd and used glibcs ifunc features to redirect functions
17:26 karolherbst: *ssh's
17:26 karolherbst: so the mere presense of the xz lib caused this backdoor to work
17:26 pac85: Uhm interesting
17:27 karolherbst: there was an MR to systemd to dlopen instead roughly a month ago which also might explain why that xz dude pressed so hard to get everybody to update
17:27 karolherbst: before everybody gets the systemd update
17:27 karolherbst: "in the past" the issue with linking against LLVM was that every drive loaded LLVM
17:28 karolherbst: *driver
17:36 dwfreed: pac85: distros tend to do immediate binding so that the table that maps symbols to addresses can be readonly at runtime
17:40 pac85: Uhm makes sense
18:14 Company: karolherbst: what I don't have understood yet is why libxz can add ifuncs to libssh
18:14 karolherbst: why can LD_PRELOAD intercept malloc?
18:15 Company: I would expect LD_PRELOAD to not be implemented via ifuncs
18:16 karolherbst: yeah.. dunno, but at least it doesn't feel like something which people tried to prevent
18:16 karolherbst: I mean..
18:16 Company: I would have expected that ifuncs come with a static table of all possible implementations
18:16 karolherbst: how do we know what a symbol is even supposed to belong to
18:17 karolherbst: it's just random strings
18:17 Company: yeah, you'd need stronger guarantees for that
18:17 Company: at which point you should probably consider static linking again
18:18 Company: you might get away with changing the symbols to refer to the library name
18:19 Company: ie instead of linking to "malloc", you make the linker refer to "libc::malloc"
18:20 Company: but I don't think this is something that libraries can solve, it needs work on the linker or maybe ELF
19:39 DavidHeidelberg: Anyone using GLUT these days (esp. for Piglit)?
19:40 DavidHeidelberg: I noticed EGL and WGL doesn't build with it, so I assume people who tests purely GLX... and I would assume that's number close to 0, but feel free to convince me otherwise
19:45 dwfreed: Company: karolherbst: https://sourceware.org/glibc/wiki/GNU_IFUNC explains a lot of this
19:47 dwfreed: iirc, the original oss-security post explained how the ifuncs contributed to wiring up the backdoor
19:52 dwfreed: the ifunc was mostly just a way to take advantage of binding not having been finished yet, so things like the PLT and GOT were still writable and could be manipulated
19:59 Company: oh, I had misread that
20:00 Company: I had thought it uses ifuncs to make the linker think there's an ifunc it should use, not that it replaced the resolver
20:04 Company: but yeah, it sounds very much like ifunc resolvers are a problem
20:06 dwfreed: they aren't in themselves; it's just they run while PLT and GOT are still writable, and so offer an attacker an ability to tell the linker to do things that affect later binding
20:10 dwfreed: they're incredibly useful normally for performance sensitive code, because they avoid the cost of using a vtable
20:27 linkmauve: “19:25:49 pac85> karolherbst: does loading llvm really make a difference if nothing that uses it is loaded? […]”, on my PinePhone, it takes about 100 ms to resolve all of LLVM’s symbols when compiled in, even though Lima doesn’t use it, that’s why I build Mesa without llvmpipe or amdgpu for my phone.
20:27 linkmauve: For every application that means about 6 frames of additional latency when opening it, not doing anything useful.
20:35 Company: sounds like it'd make sense to build things so they only link llvm on the drivers that use it?
20:36 linkmauve: Many many years ago, Mesa switched to building only a single shared object that would contain all drivers, because the downsides were less important than linking the same core parts in every single driver for distributions, I think that project was called megadrivers.
20:39 Company: I was thinking about when I build the driver on my rpi and all the time it's wasting with llvm
20:39 HdkR: dlopen for libllvm makes sense so you can namespace the binary as well
20:39 Company: though I guess I do use llvmpipe for testing, so it's not entirely bad
20:42 linkmauve: Company, nowadays there is also rusticl which needs it, so it makes sense to link it in all relevant drivers.
20:57 Ntemis: welcome
21:23 jenatali: DavidHeidelberg: there's freeglut for Windows. Why do you ask?
22:12 DavidHeidelberg: jenatali: yup, I found there was a small bug (or feature), so in cmake it looked like you need to use waffle for Windows too, but ofc it builds fine without Waffle
22:12 DavidHeidelberg: question is if it's necessary to keep GLUT around or just switch to Waffle (and remove a bit of complexity, since GLUT cannot be used for EGL for example)
22:13 jenatali: DavidHeidelberg: fine by me
22:13 jenatali: I recently (2yrs ago?) switched Mesa CI to use waffle for Windows
22:26 DavidHeidelberg: I wonder where it may cause troubles.. maybe MacOS..
22:27 DavidHeidelberg: jenatali: btw. feel free to drop a word here: https://gitlab.freedesktop.org/mesa/piglit/-/issues/101
22:28 DemiMarie: linkmauve: dlopen() makes sense for the namespacing reasons (so long as LLVM is built with `-Wl,-Bsymbolic`, which it should hopefully be, and I’m not missing anything) and to reduce startup time.