Hi, In http://reviews.llvm.org/D7424 we've been discussing whether to insert control flow integrity checks in Clang or LLVM. The main challenge is that the checks need something like a string associated with each call, and there's currently no stable way to ensure that the string stays with the call. The current version of the patch does the checks with an intrinsic, but there's a concern that this may interfere with devirtualization. Does anyone have any opinions besides what's been discussed on the review thread? Thanks, -- Peter
Rather than using a new intrinsic, you could use either patchpoint or statepoints to represent this. If you passed the string you needed tied to the call as an argument, it would end up in the stackmap section. You'd be guaranteed that the string was available throughout the optimizer as well. Philip On 02/17/2015 12:35 PM, Peter Collingbourne wrote:> Hi, > > In http://reviews.llvm.org/D7424 we've been discussing whether to insert > control flow integrity checks in Clang or LLVM. The main challenge is that > the checks need something like a string associated with each call, and > there's currently no stable way to ensure that the string stays with the call. > > The current version of the patch does the checks with an intrinsic, but > there's a concern that this may interfere with devirtualization. > > Does anyone have any opinions besides what's been discussed on the review > thread? > > Thanks,
It may be a good idea to use patchpoints (or something like them) to give a linker space to assemble a (possibly optimized based on global information) check if we wanted to drop the dependency on LTO. I'd need to think about this more though, and this is probably not something we'd want to do in version 1. In general, the idea of representing the calls as an intrinsic call taking a function pointer/args seems interesting, but it may be simplest to avoid trying to overload one of the existing intrinsics. Peter On Tue, Feb 17, 2015 at 04:22:49PM -0800, Philip Reames wrote:> Rather than using a new intrinsic, you could use either patchpoint or > statepoints to represent this. If you passed the string you needed tied > to the call as an argument, it would end up in the stackmap section. > You'd be guaranteed that the string was available throughout the > optimizer as well. > > Philip > > On 02/17/2015 12:35 PM, Peter Collingbourne wrote: >> Hi, >> >> In http://reviews.llvm.org/D7424 we've been discussing whether to insert >> control flow integrity checks in Clang or LLVM. The main challenge is that >> the checks need something like a string associated with each call, and >> there's currently no stable way to ensure that the string stays with the call. >> >> The current version of the patch does the checks with an intrinsic, but >> there's a concern that this may interfere with devirtualization. >> >> Does anyone have any opinions besides what's been discussed on the review >> thread? >> >> Thanks, > >-- Peter
On Tue, Feb 17, 2015 at 12:35 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:> Hi, > > In http://reviews.llvm.org/D7424 we've been discussing whether to insert > control flow integrity checks in Clang or LLVM. The main challenge is that > the checks need something like a string associated with each call, and > there's currently no stable way to ensure that the string stays with the > call. > > The current version of the patch does the checks with an intrinsic, but > there's a concern that this may interfere with devirtualization. > > Does anyone have any opinions besides what's been discussed on the review > thread? >My primary concern is that I would very much like the CFI implementation to be truly generic for indirect function calls rather than specific to type hierarchies. Is the issue that for virtual calls there is a dramatically cheaper way to structure the CFI implementation than there is for fully general indirect calls? Is the issue that detecting and instrumenting the calls in the IR is particularly complex? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/473ff9f8/attachment.html>
On Tue, Feb 17, 2015 at 07:00:14PM -0800, Chandler Carruth wrote:> On Tue, Feb 17, 2015 at 12:35 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > > Hi, > > > > In http://reviews.llvm.org/D7424 we've been discussing whether to insert > > control flow integrity checks in Clang or LLVM. The main challenge is that > > the checks need something like a string associated with each call, and > > there's currently no stable way to ensure that the string stays with the > > call. > > > > The current version of the patch does the checks with an intrinsic, but > > there's a concern that this may interfere with devirtualization. > > > > Does anyone have any opinions besides what's been discussed on the review > > thread? > > > > My primary concern is that I would very much like the CFI implementation to > be truly generic for indirect function calls rather than specific to type > hierarchies. > > Is the issue that for virtual calls there is a dramatically cheaper way to > structure the CFI implementation than there is for fully general indirect > calls?The main problem with a design that is fully generic to indirect calls is a lack of precision. If we design our checks independent of the type hierarchy we could permit virtual calls to a function of the wrong type if the parameter/return types would otherwise match. See also [1] which contains some discussion of precision. There are also ancillary performance benefits of this design. For example, if we lay out the type information near the virtual tables we can in some cases avoid an additional cache miss. Thanks, -- Peter [1] http://www.pcc.me.uk/~peter/acad/usenix14.pdf