| Summary: | valgrind fails to start on a FreeBSD system which enforces W^X. | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Amit <akamit91> |
| Component: | memcheck | Assignee: | Paul Floyd <pjfloyd> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | akamit91, pjfloyd |
| Priority: | NOR | ||
| Version: | 3.18.1 | ||
| Target Milestone: | --- | ||
| Platform: | FreeBSD Ports | ||
| OS: | FreeBSD | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Amit
2022-03-24 05:40:06 UTC
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 |