New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
userfaultfd backend #1
Comments
this is a compelling argument! and of course a it's not possible to observe or modify the faulting thread's context through uffd, that i know of. there's an under-documented flag to have linux report the faulting thread's tid and with that some clever ptrace could let the fault-handling thread update the faulter's thread context, maybe? i think that interacts poorly if someone were to try using a debugger on either the parent or child processes though. if you know a more fitting way to get updated information into the faulter's thread context, i'm all ears! |
I've read that Checkpoint/Restore in Userspace (CRIU) uses a parasite shellcode injected via ptrace to access thread context, so clever-ptracing is definitely possible, but you're right that preventing debuggers from attaching would be very unfortunate. For pure register reads, depending on But if the process is already ptraced and we want to write, there ought to be some very reasonable & practical alternatives!
I have not thought very deeply about any of these, and I have to apologize for inflicting this 'feature request' on you, but on the off-chance any of these might work, I couldn't miss an opportunity to make this |
regmap currently registers load-bearing SIGBUS and SIGSEGV handlers, but these have many alternative uses (stack overflow detection, core dumping/crash reporting, ON ERROR RESUME NEXT, miscellaneous PROT_NONE catching) and, unfortunately, signal disposition is hopelessly global!
userfaultd is a more general mechanism to handle page-faults in userspace (from a different thread, or from a different process). Unless disabled through
/proc/sys/vm/unprivileged_userfaultfd
, userfaultd can be used without privileges.Currently it is mostly used for migration/checkpoint-restore code, and not so much for the traditional "sigaction" use-cases, so there should be less potential conflict with other libraries, and support for full userfaultd chaining/nesting is also being thought about, something impossible with signals!
Clearly, the 8086's lack of support for memory-mapping registers is a grave oversight and Rust would greatly benefit from a
regmap
backend that is compatible with more libraries =DThe text was updated successfully, but these errors were encountered: