onars

Using your terms, it is an implementation distinction as well. You install G-Free, call 'make' to build any software, it comes out gadget free. You delete G-free, call make, it comes out with gadgets. With our prototype implementation for Linux and GCC, you don't need to touch gcc or gas or the linker or anything else. This is explained in the paper.

If you have a build system where the assembler and the compiler are bundled as a monolithic binary executable, then your argument may or may not hold.

EDIT: Just to clarify, 'make' was just an example. You can also directly call "gcc program.c" or "as anotherprogram.S" and G-Free does its job.

That being said, I must say G-Free is practical by design, ie, it can realistically be implemented and used in a production environment, as opposed to many defense solutions (for ROP or other memory corruption attacks) which are just proof of concept.

I am the author of the paper on G-Free.

G-Free does not modify the assembler, or any other component on a system. It is a completely independent layer between the compiler and the assembler. And its performance overhead is indeed surprisingly low.

Even then, there are numerous reasons I can think of why it won't immediately be included in a production environment (as won't most cutting edge research).

The first reason being, by definition, G-Free is a compiler based solution. You need the source code in order to build gadget free software. This may not be the best fit for an already established production system. However, I can imagine this system being easily adapted into a binary loader, so that it does its trick when loading a binary into the memory.

Then, you have the issues of compiler verification. You are right in saying that research quality code does not equal production quality. We do have a prototype implementation that works nicely, as described in the paper. But who am I to say it is perfect? Well, we compiled a full system with it, and have been running it without problems since then. But you never have the assurance unless you do some formal verification. I would not compile a critical piece of software (something running on an aircraft, for example) with just any implementation, without having solid ( = formal) proof that the implementation is perfect.

It is true that code-reuse attacks have been around for some time, but Shacham's paper actually showed that you can make arbitrary --Turing complete-- computations with this approach, among other things. I think this alone is a good contribution.