Doesn't this mean that the broken device also answered to every ARP request? And wouldn't that break the network by itself, regardless of DHCP behavior?
Makes sense. I was thinking that maybe signal handlers could use the regular stack of the thread, but that would of course make everything fall down if the "real" code would write to the stack before updating the stack pointer.
Oh yeah, I didn't think of that. I wonder if you could write a signal handler carefully to not allocate any memory, stack or otherwise, or is some return address or an internal structure being allocated transparently...
What happens if you really run out of physical memory (including swap) after overcommitting? Does your process get a signal, or will OOM killer just run without notifying the process that triggered the condition?
This one's my favorite (although I haven't read the whole thing):
"This movement is designed to double the speed by gears of equal diameters and numbers of teeth—a result once generally supposed to be impossible. Six bevel-gears are employed..."
I can imagine some timing-specific attacks for memory accesses, but they're not likely as robust as attacks against the branch-predictor:
1. This is the simplest one - if the memory being accessed is in a cache (L1/L2, or page in TLB), the function will take a significantly shorter time to execute. If movfuscator achieves conditional execution by manipulating index registers to perform idempotent operations, this will be very easy to detect.
2. Prefetching - if movfuscator reads memory sequentially with a detectable stride, prefetching will shorten the execution time.
3. Write combining - if the code writes to nearby addresses (same cache line), the CPU will combine them to a single write. This will cause a measurable timing difference.
EDIT: One more: Store forwarding - if the code writes to a memory address and reads it soon, the CPU may bypass the memory access (and even cache access) completely.
- User-specific bin folder ~/LocalApps (with lots of scripts)
- Projects etc. in a GoCryptFS-encrypted directory synced with Syncthing with NAS (with NFS+Kerberos on my desktop rather than Syncthing). Vendor-directories (/vendor/, /node_modules/) are not encrypted as not to slow down development, they are bind-mounted to a cleartext directory.