Do not take programming advice or security advice or, actually, any kind of advice from this man catb.org/~esr/gif2png/N
read image description
ALT
38
298
708
Conversation
This is why the manifestation of memory UB on my kernel will be untrappable abnormal exit, not a catchable signal. 😊
3
1
25
I wonder how many otherwise-legit apps catch SIGSEGV and friends? like, about the same as mmap the 0 page maybe?
9
15
No, it's very common. It's widely used in garbage collectors (instead of write barriers) and JIT compilers (for changing the code and also just for halting code execution) among other places. It's so common that userfaultfd was added as a better approach:
man7.org/linux/man-page
3
13
makes sense, I didn't know GCs used this. previously I had only seen it used in weird niches such as transparent distributed shared memory.
3
2
it seems like a crap design though. we don't want to handle every SIGSEGV, but rather only those that come from regions we've mmaped for very specific purposes.
2
3
What do you mean? GCs don't silently ignore SIGSEGVs coming from non-GC regions.
1
They still end up handling the signals for them if they're using the traditional signal handling approach though. They end up seeing that it's not inside one of their regions in their signal handler and passing it through. It's also tied to why Firefox is monkey patching libc.
right, it would be nice not to be forced to write the code discriminating between signal sources
The userfaultfd approach avoids this, among other ways that it's substantially less ugly and more efficient. It also means you don't have issues with overlapping uses of this functionality which is why Firefox is messes with libc rather than solving their internal code conflicts.
1
2
userfaultfd seems better, no doubt. Windows has something equivalent doesn't it? Does OS X, BSDs, etc have anything similar?