Prefer userfaultfd over mprotect+SIGSEGV signal handling on linux for phpdbg watchpoints

[bwoebi]

Not sure whether that's a good idea, especially unsure whether config.m4 check for userfault handling is fine. The problem with a classical "program" check where we run userfaultfd() and an ioctl() is that userfaultfd(2) may error if the user building phpdbg is not permitted to use the syscall (like it may be the case in docker - or as unprivileged user on a hardened system).

This also is much more compatible with gdb for debugging purposes (I intend on improving stability and memory leaks here in future commits...). In general, this approach seems also to be strongly recommended in Linux over the classical mprotect+SIGSEGV handling (https://www.kernel.org/doc/Documentation/vm/userfaultfd.txt).

[krakjoe]

Excellent.

…

On Thu, 7 Oct 2021 at 11:48, Bob Weinand ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In sapi/phpdbg/phpdbg_watch.c <#7551 (comment)>: > @@ -268,6 +305,29 @@ int phpdbg_watchpoint_segfault_handler(siginfo_t *info, void *context) { return SUCCESS; } +#ifdef HAVE_USERFAULTFD_WRITEFAULT +void *phpdbg_watchpoint_userfaultfd_thread(void *phpdbg_globals) { + pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL); + zend_phpdbg_globals *globals = (zend_phpdbg_globals *) phpdbg_globals; + + struct uffd_msg fault_msg = {0}; + while (read(globals->watch_userfaultfd, &fault_msg, sizeof(fault_msg)) == sizeof(fault_msg)) { + void *page = phpdbg_get_page_boundary((char *) fault_msg.arg.pagefault.address); + zend_hash_index_add_empty_element(globals->watchlist_mem, (zend_ulong) page); It isn't :-) Allocating here is actually fine, because a) it's malloc()'ed (watched memory is *supposed* to be emalloc()'ed, or the signal handler is also faulty) and b) the other thread is guaranteed to be halted (as it's pending a fault resolution here). — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#7551 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARB52WZF6OW3UZVTUIMVT3UFVUE7ANCNFSM5FIDNOPQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.