similar to: [LLVMdev] [RFC] Simple control-flow integrity

Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] [RFC] Simple control-flow integrity"

2017 May 16
2
[RFC] CFI for indirect calls with ThinLTO
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
2017 May 16
2
[RFC] CFI for indirect calls with ThinLTO
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. >> >>
2017 May 24
2
[RFC] CFI for indirect calls 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
2018 Jan 24
3
RFC: Using link-time optimization to eliminate retpolines
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
2016 Apr 07
4
RFC [ThinLTO]: Promoting more aggressively in order to reduce incremental link time and allow sharing between linkage units
> On Apr 6, 2016, at 9:40 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Wed, Apr 6, 2016 at 5:13 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: > > > On Wed, Apr 6, 2016 at 4:53 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Apr 6,
2016 Apr 07
2
RFC [ThinLTO]: Promoting more aggressively in order to reduce incremental link time and allow sharing between linkage units
On Wed, Apr 6, 2016 at 4:53 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 6, 2016, at 4:41 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > I'd like to propose changes to how we do promotion of global values in > ThinLTO. The goal here is to make it possible to pre-compile parts of the > translation unit to native code at
2018 May 01
2
ThinLTO + CFI
Jump table sections already have this prefix: ".text..L.cfi.jumptable.”, without forcing the name with setSection(). Is that good enough? > On May 1, 2018, at 1:16 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > I think we just need to change the section name for non-MachO object formats because "__TEXT,__text,regular,pure_instructions" is the default text
2018 May 01
2
ThinLTO + CFI
It’s not the functions themselves, it’s the jump tables that end up in the same section of the thin-link temporary object. If I have, say, foo and bar and both of them need a jump table entry, both entries will be in the same section of the temp object. The real functions will be renamed to foo.cfi and bar.cfi. If I list “foo.cfi, foo, bar.cfi, bar” in the link order file, the linker (I use lld)
2018 May 01
2
ThinLTO + CFI
That seems to do the trick. I get “symbol ordering file: no such symbol: <blah>” warnings for symbols that didn’t get renamed. Maybe we'll have a separate order file for CFI builds... What about the comment above that line? > On May 1, 2018, at 11:46 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Tue, May 1, 2018 at 11:29 AM, <dmitry.mikulin at
2018 May 01
0
ThinLTO + CFI
The problem as I recall was that we do not want jumptable sections to appear before __cfi_check, so we gave these jump tables a name so that the bfd default linker script would sort them after __cfi_check. This is the relevant part of the default linker script: .text : { [...] *(.text.hot .text.hot.*) *(.text .stub .text.* .gnu.linkonce.t.*) } So I guess the idea was
2018 May 02
1
ThinLTO + CFI
Taking out that line breaks some LowerTypeTest tests, need to investigate. Runtime compiler-rt all passed. > On May 1, 2018, at 3:11 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > The problem as I recall was that we do not want jumptable sections to appear before __cfi_check, so we gave these jump tables a name so that the bfd default linker script would sort them after
2018 Jan 26
0
RFC: Using link-time optimization to eliminate retpolines
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
2018 May 01
2
ThinLTO + CFI
> On Apr 30, 2018, at 6:04 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 30, 2018 at 1:05 PM, <dmitry.mikulin at sony.com> wrote: > Replacing direct calls to jump table entries with calls to real targets recovers most of the performance loss in my benchmark. Dealing with link order files is a bit cumbersome though: I can’t keep both, say “foo” and
2019 Sep 30
3
Debugging LowerTypeTests in LLVM Using GDB
Hi, I am looking into Control-Flow Integrity for indirect function calls, implemented with jump tables. I want to step through the code that produces these jump tables in GDB. I have built clang and opt from source with debugging symbols. I believe this code lives in llvm/lib/Transforms/LowerTypeTests.cpp, but when I try to debug *opt* by running the command "run -lowertypetests cfi-icall.bc
2018 Apr 30
4
ThinLTO + CFI
Replacing direct calls to jump table entries with calls to real targets recovers most of the performance loss in my benchmark. Dealing with link order files is a bit cumbersome though: I can’t keep both, say “foo” and “foo.cfi” next to each other in link order, because if both exist, the linker reorders the jump table next to the real function. This is not what we want when the goal is to get rid
2018 May 01
0
ThinLTO + CFI
I think we just need to change the section name for non-MachO object formats because "__TEXT,__text,regular,pure_instructions" is the default text section name in MachO. There seems to be a way to get the ".cfi" suffix on section names that doesn't involve setting a custom section name (which would invoke the "everything goes in the same section" behaviour), and
2018 May 01
0
ThinLTO + CFI
On Tue, May 1, 2018 at 11:29 AM, <dmitry.mikulin at sony.com> wrote: > It’s not the functions themselves, it’s the jump tables that end up in the > same section of the thin-link temporary object. If I have, say, foo and bar > and both of them need a jump table entry, both entries will be in the same > section of the temp object. The real functions will be renamed to foo.cfi >
2018 Jan 26
1
RFC: Using link-time optimization to eliminate retpolines
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
2018 May 01
0
ThinLTO + CFI
On Tue, May 1, 2018 at 11:10 AM, <dmitry.mikulin at sony.com> wrote: > > > > On Apr 30, 2018, at 6:04 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > > > On Mon, Apr 30, 2018 at 1:05 PM, <dmitry.mikulin at sony.com> wrote: > > Replacing direct calls to jump table entries with calls to real targets > recovers most of the performance
2019 Oct 14
2
[RFC] Propeller: A frame work for Post Link Optimizations
Hello, I wanted to consolidate all the discussions and our final thoughts on the concerns raised. I have attached a document consolidating it. BOLT’s performance gains inspired this work and we believe BOLT is a great piece of engineering. However, there are build environments where scalability is critical and memory limits per process are tight : * Debug Fission,