SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** valgrind fails to start on a FreeBSD system which enforces W^X. Looks like memcheck is trying to mmap with PROT_WRITE|PROT_EXEC, permissions. Is it really needed ? Or is there a option in Makefile to avoid this ? STEPS TO REPRODUCE 1. FreeBSD 13+ with W^X enforced "sysctl kern.elf64.allow_wx=0" 2. launch valgrind 3. OBSERVED RESULT ➜ ~ valgrind --version --23644:0: aspacem <<< SHOW_SEGMENTS: out_of_memory (15 segments) --23644:0: aspacem 1 segment names in 1 slots --23644:0: aspacem freelist is empty --23644:0: aspacem (0,4,5) /usr/local/libexec/valgrind/memcheck-amd64-freebsd --23644:0: aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --23644:0: aspacem 1: 0004000000-0037ffffff 832m --23644:0: aspacem 2: FILE 0038000000-00380c1fff 794624 r---- d=0x99ef79a8 i=329107 o=0 (0,4) --23644:0: aspacem 3: FILE 00380c2000-0038273fff 1777664 r-x-- d=0x99ef79a8 i=329107 o=790528 (0,4) --23644:0: aspacem 4: FILE 0038274000-0038274fff 4096 rw--- d=0x99ef79a8 i=329107 o=2564096 (0,4) --23644:0: aspacem 5: ANON 0038275000-003a849fff 37m rw--- --23644:0: aspacem 6: 003a84a000-0401ffffff 15479m --23644:0: aspacem 7: RSVN 0402000000-0402000fff 4096 ----- SmFixed --23644:0: aspacem 8: 0402001000-07ffffffff 16351m --23644:0: aspacem 9: RSVN 0800000000-0839075fff 912m ----- SmFixed --23644:0: aspacem 10: ANON 0839076000-0859055fff 511m ----- --23644:0: aspacem 11: ANON 0859056000-0859075fff 131072 rw--- --23644:0: aspacem 12: RSVN 0859076000-7fffffffefff 131038g ----- SmFixed --23644:0: aspacem 13: ANON 7ffffffff000-7fffffffffff 4096 r-x-- --23644:0: aspacem 14: RSVN 800000000000-ffffffffffffffff 16383e ----- SmFixed --23644:0: aspacem >>> --23644-- core : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --23644-- dinfo : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --23644-- (null) : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 0 rzB --23644-- demangle: 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --23644-- ttaux : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --23644-- translate: 0 guest insns, 0 traces, 0 uncond chased, 0 cond chased --23644-- translate: no SP updates identified --23644-- translate: PX: SPonly 0, UnwRegs 0, AllRegs 0, AllRegsAllInsns 0 --23644-- tt/tc: 0 tt lookups requiring 0 probes --23644-- tt/tc: 0 fast-cache updates, 0 flushes --23644-- transtab: new 0 (0 -> 0; ratio 0.0) [0 scs] avg tce size 0 --23644-- transtab: dumped 0 (0 -> ??) (sectors recycled 0) --23644-- transtab: discarded 0 (0 -> ??) --23644-- scheduler: 0 event checks. --23644-- scheduler: 0 indir transfers, 0 misses (1 in 0) .. --23644-- scheduler: .. of which: 0 hit0, 0 hit1, 0 hit2, 0 hit3, 0 missed --23644-- scheduler: 0/0 major/minor sched events. --23644-- sanity: 0 cheap, 0 expensive checks. ==23644== ==23644== Valgrind's memory management: out of memory: ==23644== newSuperblock's request for 4194304 bytes failed. ==23644== 576,544,768 bytes have already been mmap-ed ANONYMOUS. ==23644== Valgrind cannot continue. Sorry. ==23644== ==23644== There are several possible reasons for this. ==23644== - You have some kind of memory limit in place. Look at the ==23644== output of 'ulimit -a'. Is there a limit on the size of ==23644== virtual memory or address space? ==23644== - You have run out of swap space. ==23644== - Valgrind has a bug. If you think this is the case or you are ==23644== not sure, please let us know and we'll try to fix it. ==23644== Please note that programs can take substantially more memory than ==23644== normal when running under Valgrind tools, eg. up to twice or ==23644== more, depending on the tool. On a 64-bit machine, Valgrind ==23644== should be able to make use of up 32GB memory. On a 32-bit ==23644== machine, Valgrind should be able to use all the memory available ==23644== to a single process, up to 4GB if that's how you have your ==23644== kernel configured. Most 32-bit Linux setups allow a maximum of ==23644== 3GB per process. ==23644== ==23644== Whatever the reason, Valgrind cannot continue. Sorry. ➜ ~ proccontrol -m wxmap -s enable valgrind --version valgrind-3.18.1 EXPECTED RESULT valgrind should run SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION ➜ ~ truss valgrind --version mmap(0x0,135168,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34910072832 (0x820cd7000) mprotect(0x2c10a2f36000,4096,PROT_READ) = 0 (0x0) issetugid() = 0 (0x0) sigfastblock(0x1,0x2c10a2f38ad0) = 0 (0x0) open("/etc/libmap.conf",O_RDONLY|O_CLOEXEC,04063320030) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=4195,size=47,blksize=4096 }) = 0 (0x0) read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f) close(3) = 0 (0x0) open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0165) = 3 (0x3) fcntl(3,F_ISUNIONSTACK,0x0) = 0 (0x0) getdirentries(3,"\M-j\M-O\^C\0\0\0\0\0\^A\0\0\0\0"...,4096,{ 0x0 }) = 104 (0x68) open("/usr/local/etc/libmap.d/mesa.conf",O_RDONLY|O_CLOEXEC,0165) = 4 (0x4) fstat(4,{ mode=-rw-r--r-- ,inode=491804,size=38,blksize=4096 }) = 0 (0x0) read(4,"libGLX_indirect.so.0 libGLX_mesa"...,38) = 38 (0x26) close(4) = 0 (0x0) getdirentries(3,0x820cdc008,4096,{ 0x1e14e5b3 }) = 0 (0x0) close(3) = 0 (0x0) open("/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,010004427) = 3 (0x3) read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\M-.\0\0"...,128) = 128 (0x80) fstat(3,{ mode=-r--r--r-- ,inode=331815,size=302,blksize=4096 }) = 0 (0x0) pread(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,174,0x80) = 174 (0xae) close(3) = 0 (0x0) open("/lib/libc.so.7",O_RDONLY|O_CLOEXEC|O_VERIFY,012320443000) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=198291,size=2001624,blksize=131072 }) = 0 (0x0) mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34923339776 (0x82197e000) mmap(0x0,4296704,PROT_NONE,MAP_GUARD,-1,0x0) = 34932731904 (0x822273000) mmap(0x822273000,565248,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0) = 34932731904 (0x822273000) mmap(0x8222fd000,1380352,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x89000) = 34933297152 (0x8222fd000) mmap(0x82244e000,40960,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x1d9000) = 34934677504 (0x82244e000) mmap(0x822458000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x1e2000) = 34934718464 (0x822458000) mmap(0x82245e000,2285568,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 34934743040 (0x82245e000) munmap(0x82197e000,4096) = 0 (0x0) close(3) = 0 (0x0) mprotect(0x82244e000,36864,PROT_READ) = 0 (0x0) mprotect(0x82244e000,36864,PROT_READ|PROT_WRITE) = 0 (0x0) mprotect(0x82244e000,36864,PROT_READ) = 0 (0x0) readlink("/etc/malloc.conf",0x8209817f0,1024) ERR#2 'No such file or directory' issetugid() = 0 (0x0) __sysctl("vm.overcommit",2,0x82097fd7c,0x82097fd70,0x0,0) = 0 (0x0) mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(21),-1,0x0) = 34915483648 (0x821200000) mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0) = 34940534784 (0x8229e4000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(21),-1,0x0) = 34949038080 (0x823200000) getpid() = 23675 (0x5c7b) __sysctl("kern.proc.pathname.23675",4,0x820982800,0x8209827f8,0x0,0) = 0 (0x0) execve("/usr/local/libexec/valgrind/memcheck-amd64-freebsd",0x820982c90,0x8229f0000) EJUSTRETURN __sysctl("sysctl.name2oid security.bsd.unprivileged_proc_debug",2,0x3a37f870,0x3a37f848,0x38019299,36) = 0 (0x0) __sysctl("security.bsd.unprivileged_proc_debug",3,0x3a37f960,0x3a37f968,0x0,0) = 0 (0x0) getpid() = 23675 (0x5c7b) __sysctl("kern.proc.vmmap.23675",4,0x3977ddb0,0x3a37f7d0,0x0,0) = 0 (0x0) mmap(0x402001000,4194304,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) ERR#13 'Permission denied' getpid() = 23675 (0x5c7b) --23675:0: aspacem <<< SHOW_SEGMENTS: out_of_memory (15 segments) write(2,"--23675:0: aspacem <<< SHOW_SEGM"...,66) = 66 (0x42) getpid() = 23675 (0x5c7b) --23675:0: aspacem 1 segment names in 1 slots write(2,"--23675:0: aspacem 1 segment nam"...,46) = 46 (0x2e) getpid() = 23675 (0x5c7b) --23675:0: aspacem freelist is empty write(2,"--23675:0: aspacem freelist is e"...,37) = 37 (0x25) getpid() = 23675 (0x5c7b) --23675:0: aspacem (0,4,5) /usr/local/libexec/valgrind/memcheck-amd64-freebsd write(2,"--23675:0: aspacem (0,4,5) /usr/"...,78) = 78 (0x4e) getpid() = 23675 (0x5c7b) --23675:0: aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed write(2,"--23675:0: aspacem 0: RSVN 000"...,73) = 73 (0x49) getpid() = 23675 (0x5c7b) --23675:0: aspacem 1: 0004000000-0037ffffff 832m write(2,"--23675:0: aspacem 1: 000"...,59) = 59 (0x3b) getpid() = 23675 (0x5c7b) --23675:0: aspacem 2: FILE 0038000000-00380c1fff 794624 r---- d=0x99ef79a8 i=329107 o=write(2,"--23675:0: aspacem 2: FILE 003"...,90) = 90 (0x5a) 0 (0,4) write(2,"0 (0,4)\n",14) = 14 (0xe) getpid() = 23675 (0x5c7b) --23675:0: aspacem 3: FILE 00380c2000-0038273fff 1777664 r-x-- d=0x99ef79a8 i=329107 o=write(2,"--23675:0: aspacem 3: FILE 003"...,90) = 90 (0x5a) 790528 (0,4) write(2,"790528 (0,4)\n",14) = 14 (0xe) getpid() = 23675 (0x5c7b) --23675:0: aspacem 4: FILE 0038274000-0038274fff 4096 rw--- d=0x99ef79a8 i=329107 o=write(2,"--23675:0: aspacem 4: FILE 003"...,90) = 90 (0x5a) 2564096 (0,4) write(2,"2564096 (0,4)\n",14) = 14 (0xe) getpid() = 23675 (0x5c7b) --23675:0: aspacem 5: ANON 0038275000-003a849fff 37m rw--- write(2,"--23675:0: aspacem 5: ANON 003"...,65) = 65 (0x41) getpid() = 23675 (0x5c7b) --23675:0: aspacem 6: 003a84a000-0401ffffff 15479m write(2,"--23675:0: aspacem 6: 003"...,59) = 59 (0x3b) getpid() = 23675 (0x5c7b) --23675:0: aspacem 7: RSVN 0402000000-0402000fff 4096 ----- SmFixed write(2,"--23675:0: aspacem 7: RSVN 040"...,73) = 73 (0x49) getpid() = 23675 (0x5c7b) --23675:0: aspacem 8: 0402001000-07ffffffff 16351m write(2,"--23675:0: aspacem 8: 040"...,59) = 59 (0x3b) getpid() = 23675 (0x5c7b) --23675:0: aspacem 9: RSVN 0800000000-0839051fff 912m ----- SmFixed write(2,"--23675:0: aspacem 9: RSVN 080"...,73) = 73 (0x49) getpid() = 23675 (0x5c7b) --23675:0: aspacem 10: ANON 0839052000-0859031fff 511m ----- write(2,"--23675:0: aspacem 10: ANON 083"...,65) = 65 (0x41) getpid() = 23675 (0x5c7b) --23675:0: aspacem 11: ANON 0859032000-0859051fff 131072 rw--- write(2,"--23675:0: aspacem 11: ANON 085"...,65) = 65 (0x41) getpid() = 23675 (0x5c7b) --23675:0: aspacem 12: RSVN 0859052000-7fffffffefff 131038g ----- SmFixed write(2,"--23675:0: aspacem 12: RSVN 085"...,75) = 75 (0x4b) getpid() = 23675 (0x5c7b) --23675:0: aspacem 13: ANON 7ffffffff000-7fffffffffff 4096 r-x-- write(2,"--23675:0: aspacem 13: ANON 7ff"...,69) = 69 (0x45) getpid() = 23675 (0x5c7b) --23675:0: aspacem 14: RSVN 800000000000-ffffffffffffffff 16383e ----- SmFixed write(2,"--23675:0: aspacem 14: RSVN 800"...,81) = 81 (0x51) getpid() = 23675 (0x5c7b) --23675:0: aspacem >>> write(2,"--23675:0: aspacem >>>\n",23) = 23 (0x17) getpid() = 23675 (0x5c7b) --23675-- core : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB write(2,"--23675-- core : "...,208) = 208 (0xd0) getpid() = 23675 (0x5c7b) --23675-- dinfo : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB write(2,"--23675-- dinfo : "...,208) = 208 (0xd0) getpid() = 23675 (0x5c7b) --23675-- (null) : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 0 rzB write(2,"--23675-- (null) : "...,208) = 208 (0xd0) getpid() = 23675 (0x5c7b) --23675-- demangle: 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB write(2,"--23675-- demangle: "...,208) = 208 (0xd0) getpid() = 23675 (0x5c7b) --23675-- ttaux : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB write(2,"--23675-- ttaux : "...,208) = 208 (0xd0) getpid() = 23675 (0x5c7b) --23675-- translate: 0 guest insns, 0 traces, 0 uncond chased, 0 cond chased write(2,"--23675-- translate: 0 guest ins"...,77) = 77 (0x4d) getpid() = 23675 (0x5c7b) --23675-- translate: no SP updates identified write(2,"--23675-- translate: no SP updat"...,46) = 46 (0x2e) getpid() = 23675 (0x5c7b) --23675-- translate: PX: SPonly 0, UnwRegs 0, AllRegs 0, AllRegsAllInsns 0 write(2,"--23675-- translate: PX: SPonly "...,78) = 78 (0x4e) getpid() = 23675 (0x5c7b) --23675-- tt/tc: 0 tt lookups requiring 0 probes write(2,"--23675-- tt/tc: 0 tt lookup"...,53) = 53 (0x35) getpid() = 23675 (0x5c7b) --23675-- tt/tc: 0 fast-cache updates, 0 flushes write(2,"--23675-- tt/tc: 0 fast-cach"...,53) = 53 (0x35) getpid() = 23675 (0x5c7b) --23675-- transtab: new 0 (0 -> 0; ratio 0.0) [0 scs] avg tce size 0 write(2,"--23675-- transtab: new "...,77) = 77 (0x4d) getpid() = 23675 (0x5c7b) --23675-- transtab: dumped 0 (0 -> ??) (sectors recycled 0) write(2,"--23675-- transtab: dumped "...,65) = 65 (0x41) getpid() = 23675 (0x5c7b) --23675-- transtab: discarded 0 (0 -> ??) write(2,"--23675-- transtab: discarded "...,44) = 44 (0x2c) getpid() = 23675 (0x5c7b) --23675-- scheduler: 0 event checks. write(2,"--23675-- scheduler: 0 event che"...,37) = 37 (0x25) getpid() = 23675 (0x5c7b) --23675-- scheduler: 0 indir transfers, 0 misses (1 in 0) .. write(2,"--23675-- scheduler: 0 indir tra"...,61) = 61 (0x3d) getpid() = 23675 (0x5c7b) --23675-- scheduler: .. of which: 0 hit0, 0 hit1, 0 hit2, 0 hit3, 0 missed write(2,"--23675-- scheduler: .. of which"...,75) = 75 (0x4b) getpid() = 23675 (0x5c7b) --23675-- scheduler: 0/0 major/minor sched events. write(2,"--23675-- scheduler: 0/0 major/m"...,51) = 51 (0x33) getpid() = 23675 (0x5c7b) --23675-- sanity: 0 cheap, 0 expensive checks. write(2,"--23675-- sanity: 0 cheap, 0 "...,50) = 50 (0x32) mmap(0x402001000,4194304,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) ERR#13 'Permission denied' getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) ==23675== ==23675== Valgrind's memory management: out of memory: ==23675== newSuperblock's request for 4194304 bytes failed. ==23675== 576,544,768 bytes have already been mmap-ed ANONYMOUS. ==23675== Valgrind cannot continue. Sorry. ==23675== ==23675== There are several possible reasons for this. ==23675== - You have some kind of memory limit in place. Look at the ==23675== output of 'ulimit -a'. Is there a limit on the size of ==23675== virtual memory or addwrite(2,"==23675== \n==23675== Valgri"...,512) = 512 (0x200) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) ress space? ==23675== - You have run out of swap space. ==23675== - Valgrind has a bug. If you think this is the case or you are ==23675== not sure, please let us know and we'll try to fix it. ==23675== Please note that programs can take substantially more memory than ==23675== normal when running under Valgrind tools, eg. up to twice or ==23675== more, depending on the tool. On a 64-bit machine, Valgrind ==23675== should be able to make use of up 32GB memory. On a 32-bit ==23675== write(2,"ress space?\n==23675== - You"...,519) = 519 (0x207) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) getpid() = 23675 (0x5c7b) machine, Valgrind should be able to use all the memory available ==23675== to a single process, up to 4GB if that's how you have your ==23675== kernel configured. Most 32-bit Linux setups allow a maximum of ==23675== 3GB per process. ==23675== ==23675== Whatever the reason, Valgrind cannot continue. Sorry. write(2," machine, Valgrind should be a"...,330) = 330 (0x14a) exit(0x1) process exit, rval = 1
There is no make option, I'm fairly certain. I also believe that it really is necessary. Roughly speaking the Valgrind startup process is 1) 'valgrind' runs and execs the tool (e.g., memcheck, which I'll use from here on) 2) memcheck is a standalone exe not linked with any libraries, so it has to bootstrap itself 3) when the guest runs (starting the ld.so to load the guest exe into memory) it will be doing RX mmaps 4) memcheck monitors the mmaping and records the access control As a workaround, don't use "sysctl kern.elf64.allow_wx=0" As a fix, I'll add a check if this is set and print a message saying that you need to turn it on. I already do this with "security.bsd.unprivileged_proc_debug=1".
(In reply to Paul Floyd from comment #1) > There is no make option, I'm fairly certain. > > I also believe that it really is necessary. > > Roughly speaking the Valgrind startup process is > > 1) 'valgrind' runs and execs the tool (e.g., memcheck, which I'll use from > here on) > 2) memcheck is a standalone exe not linked with any libraries, so it has to > bootstrap itself > 3) when the guest runs (starting the ld.so to load the guest exe into > memory) it will be doing RX mmaps RX mapping should not be issues , or do you mean WX/RWX mapping ? > 4) memcheck monitors the mmaping and records the access control > > As a workaround, don't use "sysctl kern.elf64.allow_wx=0" > > As a fix, I'll add a check if this is set and print a message saying that > you need to turn it on. I already do this with > "security.bsd.unprivileged_proc_debug=1". as a work around you can also use proccontrol ("proccontrol -m wxmap -s enable valgrind") to let valgrind do WX map, which personally I think is much secure https://www.freebsd.org/cgi/man.cgi?query=proccontrol&apropos=0&sektion=1&manpath=FreeBSD+14.0-current&arch=default&format=html
Yes, I meant WX. I can add proccontrol to the message.
(In reply to Paul Floyd from comment #3) > Yes, I meant WX. I can add proccontrol to the message. LGTM
What I have so far paulf> sudo sysctl kern.elf64.allow_wx=0 kern.elf64.allow_wx: 1 -> 0 euler:/usr/home/paulf paulf> /home/paulf/scratch/valgrind/vg-in-place --help --6689:0: main Valgrind: FATAL: --6689:0: main sysctl kern.elf64.allow_wx sysctl is 0. --6689:0: main Set this sysctl with --6689:0: main 'sysctl kern.elf64.allow_wx sysctl=1'. --6689:0: main Or, alternatively, run valgrind with --6689:0: main 'proccontrol -m wxmap -s enable valgrind [options] prog-and-args' --6689:0: main Cannot continue. It seems to me that proccontrol -m wxmap is only on FreeBSD 14. kern.elf64.allow_wx sysctl is in FreeBSD 13, do you know if it is also in 12.3?
(In reply to Paul Floyd from comment #5) > What I have so far > > paulf> sudo sysctl kern.elf64.allow_wx=0 > kern.elf64.allow_wx: 1 -> 0 > euler:/usr/home/paulf > paulf> /home/paulf/scratch/valgrind/vg-in-place --help > --6689:0: main Valgrind: FATAL: > --6689:0: main sysctl kern.elf64.allow_wx sysctl is 0. > --6689:0: main Set this sysctl with > --6689:0: main 'sysctl kern.elf64.allow_wx sysctl=1'. > --6689:0: main Or, alternatively, run valgrind with > --6689:0: main 'proccontrol -m wxmap -s enable valgrind [options] > prog-and-args' > --6689:0: main Cannot continue. > > It seems to me that proccontrol -m wxmap is only on FreeBSD 14. > Yes as of now as of now its only in FreeBSD14 , but it seems it might get back ported in upcoming FreeBSD13.1 release > kern.elf64.allow_wx sysctl is in FreeBSD 13, do you know if it is also in > 12.3? kern.elf64.allow_wx sysctl was added in FreeBSD together with W^X feature, so if you are on a FreeBSD release that doesn't have kern.elf64.allow_wx , valgrind should have no issues doing WX map.
I need to check my changes on 12.[23] and I'll spin up a 13.1 beta VM. I expect that this change will be in Valgrind 3.19 which is due in the next couple of weeks. When that is out I'll bump up the devel/valgrind port.
I also need to add and test kern.elf32.allow_wx
Also, for a build time possible fix, there's -Wl,-z,wxneeded see https://forums.freebsd.org/threads/rclone-not-working-with-w-x.80279/
(In reply to Paul Floyd from comment #9) > Also, for a build time possible fix, there's -Wl,-z,wxneeded > > see > > https://forums.freebsd.org/threads/rclone-not-working-with-w-x.80279/ Yes , I tried that https://www.freebsd.org/cgi/man.cgi?query=ld.lld&sektion=1&manpath=freebsd-release-ports But there's is a myriad of Makefiles and custom linking script, so I failed to implement that, if you can do it, it would be nice. The other fix I could suggest is , map with RW protection first , till you need the write permissions then do mprotect https://www.freebsd.org/cgi/man.cgi?sektion=2&query=mprotect and change the mapping to RX before the coded in the mapped memory needs execution.
I don't think that it's worth even trying to change the mmap attributes. If the guest does WX mapping then it'll also happen when running under Valgrind. Enforcing W^X would mean a lot of new housekeeping.
yeah, sysctl and proccontrol workaround is enough.
Last night I checked 13.1 BETA3 and it does have the proccontrol option.
In the end I don't see how to get proccontrol to work (the sysctl still says that allow_wx is 0). So I just put the sysctl instructions in the message. commit bbc3bcab0ae7aa01a116c05c52c66a6714a7df12 (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Sun Apr 3 15:50:38 2022 +0200