> I read "hacking blind." Can you restart a daemon with another forked > process that's only job is to monitor a pipe or a waitpid()-like operation > and if the parent dies, it exec's to restart it, or even execs "rcctl > restart ntpd" > > If the mitigations are successful at limiting execution to let's say, > overwriting a canary that gets completely rerandomized with a fork-exec, > instead of just a fork, it would stop a meaningful search for the correct > canary to just blind luck instead of byte by byte discovery.
your position is very roughly: that paper lays out the absolute limit of what someone could learn from broken software, so as long as we run a new copy of the broken software we'll be safe........ obviously, no downside. you say "completely rerandomized" -- uhm no, only a tiny fraction of the program execution environment and runtime are randomized, in particular same registers used everywhere, same instruction sequences, same frame layouts, same register and stack leave-behinds, same relative offsets inside each DSO.... nothing learned from re-running buggy software? sorry, that is BS.
