alt.hn

6/1/2026 at 3:15:11 AM

Weekend trivia: your process' memory is a file

https://lcamtuf.substack.com/p/weekend-trivia-your-process-memory

by surprisetalk

6/1/2026 at 10:25:45 AM

We use this trick of writing to /proc/<pid>/mem in safety-critical programming to test all the fail cases required to get to 100% code-coverage, tested.

Its quite handy to be able to inject error data directly into a process-under-test and be sure that the exception code actually gets run.

Another thing we do is write to /dev/kmem (or more recently, /dev/kcore), which has to be explicitly enabled, for the purposes of crashing the kernel and ensuring that the system recovers as expected. This particular trick is so interesting to learn, if you're a systems programmer .. with the appropriate System.map, you can steer the kernel around entirely through calculated writes to /dev/kmem, in interesting ways .. find your way to the kernels' jiffies, and see what fun can be had!

Of course, this is all being supplanted by kprobes and eBPF, but back in the day it sure was fun to write tests with the dd tool .. ;)

by aa-jv

6/1/2026 at 12:32:36 PM

One day I forgot about SIGSTOP in a FAANG interview when asked how to stop a forkbomb that already exhausted all PIDs but you have a shell already running.

My very dirty trick at last was to abuse the part where forkbomb's code segments should be shared mapping, find out where it is in memory, then do corewars style overwrite with piece of code that would cause the process to exit (corewars classic would be divide by zero).

Nevertheless, I should have used SIGSTOP xD

by p_l