similar to: [CFI] Manually linking classes that have no inheritance link

Hi Kostya, Please find attached the minimized motivation test. I hope it is minimized enough. If not please let me know so I can try to make it more minimal. Were you expecting something like this? Also I think the tests that I should provide along with the patch should be in a special format right? I think I should be looking at http://llvm.org/docs/DeveloperPolicy.html#test-cases, and

-krasin@ On Fri, Jun 16, 2017 at 11:05 AM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Jun 15, 2017 at 10:39 PM, Enes Göktaş <enes.goktas at gmail.com> > wrote: > >> Hi Kostya, >> >> Please find attached the minimized motivation test. >> I hope it is minimized enough. If not please let me know so I can try to >> make it more

As you noted the class links are actually of the whitelisting kind and not of the blacklisting kind. Doing this with an attribute is pretty interesting and sounds like a better fit to me. I think this could look something like: __attribute__((compatible_vtable_layout("JSComponentMath", "JSComponentImage"))) class ProxyClass{ public: ... } Would this be more admissible? On

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,

On Mon, May 15, 2017 at 6:44 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sending this out. A few comments below. > > On Mon, May 15, 2017 at 5:17 PM, Evgenii Stepanov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> this is a proposal for the implementation of CFI-icall [1] with ThinLTO. >> >>

On Tue, May 23, 2017 at 4:39 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com > wrote: > On Tue, May 16, 2017 at 4:33 PM, Evgenii Stepanov > <eugeni.stepanov at gmail.com> wrote: > > On Mon, May 15, 2017 at 6:44 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Thanks for sending this out. A few comments below. > >> > >> On

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

Hi, this is a proposal for the implementation of CFI-icall [1] with ThinLTO. Jumptables are generated in the merged module. To generate a jumptable, we need a list of functions with !type annotations, including (in non-cross-dso mode) external functions. Unfortunately, LLVM IR does not preserve unused function declarations, and we don’t want to copy the actual function bodies to the merged

The proposed mitigation for variant 2 of CVE-2017-5715, “branch target injection”, is to send all indirect branches through an instruction sequence known as a retpoline. Because the purpose of a retpoline is to prevent attacker-controlled speculation, we also end up losing the benefits of benign speculation, which can lead to a measurable loss of performance. We can regain some of those benefits

Wouldn't a branch funnel open the door to a type 1 attack? E.g. if the code looks like this, then a branch funnel basically turns into a standard type 1 pattern AFAICT: struct Base { virtual int f(long) = 0; }; struct A : Base { int f(long x) override { return 0; }; }; struct B : Base { int f(long x) override { // As in listing 1 in

Hi all, The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call optimization. 2. It is represented using a global named metadata node, rather than

Hi, Sean Silva via llvm-dev wrote: > Wouldn't a branch funnel open the door to a type 1 attack? Only if the code looks exactly as you wrote it. If I understand this correctly the problem with indirect branches is that the "gadget", the code leaking the data, could be *anywhere* in the binary, giving the attacker much more freedom. So restricting these calls to one of the

Hi all, As promised, here is a brain dump on how I see CFI for vcalls working under ThinLTO. Most of this has been prototyped, so the design does appear to be sound. For context on how CFI currently works under regular LTO, please read: http://llvm.org/docs/TypeMetadata.html http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html http://clang.llvm.org/docs/LTOVisibility.html ==== Summary

Hi Peter, Thanks for sending this and sorry for the slow response. Some questions below. Teresa On Tue, Oct 25, 2016 at 5:27 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > > As promised, here is a brain dump on how I see CFI for vcalls working > under ThinLTO. Most of this has been prototyped, so the design does appear > to be sound. For context on how CFI

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

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

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

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

2015-09-01 11:38 GMT+08:00 John Criswell <jtcriswel at gmail.com>: > On 8/31/15 10:43 PM, 慕冬亮 via llvm-dev wrote: > > I want to create an experiment to show the effectiveness of cfi : > For example , > I first need a program with vulnerability so that we can hijack its > control flow; > > then I enforce cfi of llvm and we can't hijack its control flow. > >

Hi Rafael, I've been staring at the CFI directives and have a question. Some background: I want to generate the compact unwind information using just the CFI directives. I *think* that this should be doable. The issue I'm facing right now is that I need to know how much the stack pointer was adjusted. So when I have something like this: .cfi_startproc Lfunc_begin175: