On 19 Sep 2015 at 17:45, Alex Efros wrote: > > so try "readelf -edW /usr/lib64/opengl/nvidia/lib/libGLdispatch.so.0" > > and post its output. > > Section Headers: > [Nr] Name Type Address Off Size ES > Flg Lk Inf Al > [10] wtext PROGBITS 0000000000048000 048000 012000 00 > AX 0 0 4096
this is an interesting section as i guess it's meant to be writable at runtime (probably stands for 'w'ritable 'text') even though it's placed an r-x segment so probably there's an explicit mprotect call later to make it writable (temporarily or permanently). > Dynamic section at offset 0x77370 contains 23 entries: > Tag Type Name/Value > 0x0000000000000016 (TEXTREL) 0x0 this mark is normally emitted by the linker when the binary will need runtime text relocations but as i said, there's no such thing under the amd64 ABI. so this makes me think that barring some toolchain bug on their end, it may be a trick to actually accomodate PaX users as the already mentioned ELFRELOCS feature will allow text relocations by allowing a one-time transition of r-x -> rw- -> r-x that ld.so uses to perform text relocations. and it so happens that i restrict this capability to files that are actually marked with DT_TEXTREL (otherwise upon enabling this kernel option any program and thus exploit could abuse this to circumvent MPROTECT). so there're two things left to do: 1. enable ELFRELOCS in your kernel config (and keep MPROTECT enforced on all binaries) 2. perhaps ask nvidia if this textrel marking is intentional my guess is that this will get you an nvidia based system where you actually no longer have to disable MPROTECT on all binaries that use their GL library which would be a marked improvement, especially if this wtext thing doesn't stay writable for all eternity and goes back to r-x after some initial runtime codegen is done there (you can check that in /proc/pid/maps).
