similar to: RFC: a renaming/redesign for LLVM's bitset metadata

On Sat, Jan 31, 2015 at 11:35:01AM -0800, JF Bastien wrote: > Trying to summarize all opinions expressed here: Peter is proposing an > initial implementation that would only work with LTO. Folks seem put off by > this implementation affecting IR without having proven itself, and having > shortcomings (as Jim pointed out). Kostya proposed going through metadata > (and Chris kind of

Hi Chris, I wanted to start by giving an explanation of what I am trying to achieve and how I am trying to achieve it. I am working towards introducing into LLVM a security mechanism, Forward Control Flow Integrity (CFI), that is designed to mitigate against vulnerabilities that allow attacks based on corrupting vtable or function pointers in memory in order to subvert a program's control

On Sat, Jan 31, 2015 at 2:07 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Sat, Jan 31, 2015 at 11:35:01AM -0800, JF Bastien wrote: > > Trying to summarize all opinions expressed here: Peter is proposing an > > initial implementation that would only work with LTO. Folks seem put off > by > > this implementation affecting IR without having proven itself,

Trying to summarize all opinions expressed here: Peter is proposing an initial implementation that would only work with LTO. Folks seem put off by this implementation affecting IR without having proven itself, and having shortcomings (as Jim pointed out). Kostya proposed going through metadata (and Chris kind of did too by mentioning tbaa), but Peter points out that this will make the

Hi all, I would like to propose a mechanism that allows IR modules to co-operatively build a pointer set corresponding to addresses within a given set of globals. The specific use case I have in mind is to provide a mechanism for a C++ program to efficiently verify (at each call site) that a vtable pointer is in the set of valid vtable pointers for the class or its derived classes. One way of

I would start from using module-level metadata. An IR extension might be a good idea once we show that - the proposed indirect call protection mechanism is efficient and useful, and - there are other use cases for the IR extension. --kcc On Wed, Jan 28, 2015 at 2:57 AM, Sean Silva <chisophugis at gmail.com> wrote: > Is there any way to accomplish this that doesn't require

So, bitset would be a property that means : globals with the same name will append on a string of bits in the order in which they appear, and it's the job of the front end to make sure the correct order is followed in every unit, so that linking does the right job in every corner case? Could that be used for efficient global boolean flags, like LLVM's options? Even if you don't need

Hi all, I'd like to make a proposal to implement the new vtable ABI described in PR26723, which I'll call the relative ABI. That bug gives more details and justification for that ABI. The user interface for the new ABI would be that -fwhole-program-vtables would take an optional value indicating which aspects of the program have whole-program scope. For example, the existing

On Thu, Jan 29, 2015 at 02:22:48PM -0800, Peter Collingbourne wrote: > I've been working on a patch that implements the bitset attribute and bitset > lowering pass. I'll see if I can send it out later today. http://reviews.llvm.org/D7288 Thanks, -- Peter

> On Jan 29, 2015, at 6:50 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Thu, Jan 29, 2015 at 02:22:48PM -0800, Peter Collingbourne wrote: >> I've been working on a patch that implements the bitset attribute and bitset >> lowering pass. I'll see if I can send it out later today. > > http://reviews.llvm.org/D7288

Using relative offsets applies to more than just vtables. It would do wonders for constant strings too. -- Sean Silva On Mon, Feb 29, 2016 at 1:53 PM, Peter Collingbourne via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi all, > > I'd like to make a proposal to implement the new vtable ABI described in > PR26723, which I'll call the relative ABI. That bug gives more

Hi all, I wanted to make this proposal to extend ThinLTO to allow a bitcode module to embed another bitcode module containing summary information. The purpose of doing so is to support CFI and whole-program devirtualization optimizations under ThinLTO. Overview The CFI and whole-program devirtualization optimizations work by transforming vtables according to the class hierarchy. For example,

Hi all, I'd like to make the following proposal to implement an optimization called virtual constant propagation. ==Introduction== After enabling control flow integrity protection in Chromium, we have observed an unacceptable performance regression in certain critical layout microbenchmarks. Profiling [0] revealed that the cause of the regression was a large number of virtual calls, each

Hi, I just thought about another use case: VTable compression. If you know that an entry in the Vtable is never used, just remove it! I’d hope we could even eliminate some unused virtual functions from the final binary. — Mehdi > On Jan 27, 2016, at 10:29 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Peter, > > Pete (Cooper, CC'ed) had a

On Tue, Feb 03, 2015 at 04:03:45PM -0800, Sean Silva wrote: > One other thing: if this can be used for control-flow integrity, I assume > it has to have good knowledge of the available indirect call targets. Could > we also use this information for devirtualization? I would expect so. If a bitset contains only one element, we should be able to teach the lowering pass to simply test that

Hi Peter, Thanks for your answer! > On Jan 28, 2016, at 10:17 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hans wrote: >> (and start-up time if we can drop the vtables and >> void the dynamic relocations). > > On Thu, Jan 28, 2016 at 09:15:05AM -0800, Mehdi Amini wrote: >> Hi, >> >> I just thought about another use case: VTable

On Sat, Jan 31, 2015 at 02:17:22PM -0800, JF Bastien wrote: > On Sat, Jan 31, 2015 at 2:07 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > > On Sat, Jan 31, 2015 at 11:35:01AM -0800, JF Bastien wrote: > > > Trying to summarize all opinions expressed here: Peter is proposing an > > > initial implementation that would only work with LTO. Folks seem

On Sat, Jan 31, 2015 at 02:53:40PM -0800, JF Bastien wrote: > > > > > The one think we need to ensure is that your metadata can be dropped by > > the > > > optimizer and the code remains correct. I'm guessing no vtable would mean > > > anything goes (not check)? That's bad security-wise, but it'll at least > > > work. We may want to make

Hi all, I'd like to add support for metadata attachments for global variables in the same way as we did for functions. Syntax would be pretty simple: @foo = global i32 0, !foo !0, !bar !1 (the extra commas are required to disambiguate from a named metadata on the next line) Benefits: 1) Lets us reverse the DIGlobalVariable -> GlobalVariable edge, which should hopefully clear the way for

Hi Peter, Please forgive if this is an obvious question, but how reasonable is it for this approach to work when not all translation units are available to be rebuilt with the new information? I'm very interested in what you're proposing here. Jim Sent from my iPhone > On Jan 27, 2015, at 1:07 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > I