[LLVMdev] [RFC] Simple control-flow integrity

[Peter Collingbourne]

> The way I've implemented it (see the patch I sent to llvm-commits
> yesterday), it's not just metadata: the intrinsic lowers to the
> jumptable entry code given above. The CFI pass then generates a
> function for each jump table; the function consists solely of these
> intrinsic calls.

Well, the intrinsic you proposed has no effect on the caller and has
non-local effects on other specified functions. I'm not aware of any other
intrinsic with similar behavior.

On Fri, Mar 21, 2014 at 12:01:24PM -0700, Tom Roeder wrote:
> On Fri, Mar 21, 2014 at 11:46 AM, Tom Roeder <tmroeder at google.com> wrote:
> > On Thu, Mar 20, 2014 at 3:29 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> >>
> >>
> >> An alternative proposal: introduce a new function attribute named, say,
> >> 'jumptable', which would cause the backend to emit a jump table entry and
> >> redirect function references other than calls through the jump table. (Direct
> >> function calls could call the original function directly, as an optimization.)
> >>
> >> The CFI pass could then consist of marking every address-taken function with
> >> 'jumptable' and introducing the pointer safety checks at call sites.
> >
> > That's an interesting suggestion. I'll look into it.
> 
> However, adding a new function attribute would require changing the
> bitcode format, right? I thought that was to be avoided in general.
> I'm not sure it makes sense to change the bitcode format to support
> CFI.

The bitcode format is not required to be kept stable. We've added attributes
in the past to support the sanitizers and stack protection among other things,
so I don't think it should be a problem to add an attribute for CFI.

Thanks,
-- 
Peter