On Wed, 02 Oct 2019 07:24:46 -0600 "Theo de Raadt" <dera...@openbsd.org> wrote: >> As far as my test (the log attached), valgrind seems to work with >> "pledge" but not work with "unveil". >> >> Is there any fundamental problem of valgrind to work with "pledge"? > > If unveil causes problems, then that means it is trying to access files. > unveil will return ENOENT or EACCES for files which you think exist, > but they've become invisible.
I looked into the problem more. - unveil(2) itself fails - so file system related system calls are not restricted (yet) valgrind complains: ==13326== --13326-- WARNING: unhandled syscall: 114 --13326-- You may be able to write your own handler. --13326-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --13326-- Nevertheless we consider this a bug. Please report --13326-- it at http://valgrind.org/support/bug_reports.html. valgrind doesn't support unveil(2) yet. I suppose Asou can add that. > But pledge is somewhat similar. It also has options to block path access, > and they are used in programs throughout our tree. In those instances, rather > than the operation failing with an error, the process will get killed hard. Yes. If valgrind does file access or uses system calls not pledged, it will not work. > So I'm sure there are circumstances it won't work, unless redesigned > into the classic "startup code / main loop code" split, where startup > has full syscall request capabilities, but it recognizes later "main > loop" code could be very lacking. It might be true. It once worked on OpenBSD, but soon it was broken before I use it. I'm not sure it works, but I'd like to try valgrind for practical problems. --yasuoka
