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
The reason is that when doing a copying (moving) collection cycle to compact the heap, they need to intercept and handle writes from other threads to the portion of the heap they're currently in the process of moving. I don't know all the details of this in a modern GC though.
The alternative to using memory protection is having write barrier checks slowing down code even when a GC isn't in process. Reads are fine because they aren't going to make the new compacted heap inconsistent with the old one. Only writes need to be intercepted/handled somehow.
1
We have known this was the root of the issue for an embarrassingly long time and still have no hardware primitives for fast conditional memory traps at a fine grain (MMU storms don't count). And Intel is over here developing Minix webservers on ME.
