Platform Provider's nightMare - code injection

I learnt of Google's decision to block code injection in Chrome processes and McAfee's reaction to it's impact on DLP software providers, including theirs, via Brian Reed's tweet.  Code injection is a topic that is viewed as a nightmare by software platform providers and as something inevitable by some ISVs like security software makers and developer tools builders.  That was a decade or two back or at least it should have been that way!  The fact that we are still stagnating by using classic means to inject, hook and patch is why we are still having this tug of war between platform providers and other ISVs on this matter.

In their defense, platform providers have tried to provide extensions and APIs as an alternate to dissuade ISVs from injecting code the way we do.  However, they are not nearly powerful enough for ISV needs and thus ISVs ultimately resort to much cruder means like code injection.  And Google Chrome team, as Microsoft has realized for sometime now, is right in thinking that approaches like code injection is a significant cause for instability introduced into their environment.  ISVs on the other hand have tried to make the injection process more stable by navigating away from chasing byte code patterns which are likely to break even with the release of a service pack to relying on more static regions that are less likely to break.  Nevertheless, it is not 100% failsafe and thus the tug of war between platform providers and ISVs.

Rather than having to sacrifice useful features because of changes to the platform that leaves them crippled, ISVs ought to have caught up to more sophisticated means towards achieving the equivalency of code injection.  As long as we are in a headlock working at the same level in the software stack, platform providers, as those hosting that layer are bound to have their way and for their own good.  Security software makers ought to have moved one layer down already to be able to better monitor the platform they are trying to secure.  Having a thin layer of Microvisor or hypervisor to accomplish just this is inevitable for any security software maker.  In fact, McAfee itself has or had DeepSafe technology that could have helped with just this kind of situation.  Of course, as the use of such technologies become ubiquitous, we are going to have to battle problems relating to chaining of Microvisors/hypervisors, bottlenecks in that area and other problems as that layer gets more attention.  At that point hardware support/awareness for such needs is likely to gain traction.  Nevertheless, we should have by now moved out of the layer in which we are fighting this code injection problem and the fact that we haven't fully is why there is this tug of war.  DLP and other software shouldn't have to suffer because we are not catching up to this need fast enough.