[...] 

>> I added the patches/ directory to the project to try out this approach
>> in applying a few CVE fixes.  I built a base patching shared library
>> that reads and applies a patch description array.  New patched code is
>> also included in this shared library.  The patching mechanism applies a
>> code-trampoline at given locations routing the binary away from the old
>> code and into the newly loaded patched code.
>>
>> It's only a proof-of-concept, but I did record a few .gif terminal
>> sessions to show what's possible:

I spent some time researching dynamic instrumentation for tracing a
few years back . We started with a ptrace based approach and developed
kaji (https://github.com/5kg/kaji) as a demo for inserting precompiled
lttng tracepoints. This was also tested with dyninst. Here are some
observations (http://www.dorsal.polymtl.ca/fr/system/files/11Dec2013.pdf).
Here is also some investigation on what happens underneath
(https://github.com/tuxology/lttng-ubench/blob/master/analysis/instr/dyninst_kaji).

In addition, some other things to look out for would be :
1. Fast Tracepoints in GDB that use a similar trampoline approach
2. SystemTap's Stapdyn approach which uses dyninst
(https://research.cs.wisc.edu/htcondor/HTCondorWeek2013/paradyn-slides/stone-stapdyn.pdf)
3. DynamoRIO (http://www.dynamorio.org/)

Also, some folks I know have complained about dynins't huge memory
consumption in a production simulation. I have not investigated that
myself, but I can if we are heading in this direction. Also, it may be
worthwhile to discuss if "spin-your-own" may be beneficial than an
available and tested framework. For example, Dyninst does recursive
trampoline checks and some other basic safety checks on snippets
before inserting them. It seems overkill in some places, but sometimes
it may add to robustness.