[llvm-dev] RFC: Using link-time optimization to eliminate retpolines

Das, Dibyendu via llvm-dev
Wed, 24 Jan 2018 16:47:59 -0000

Can you run your new patch on CPU2017 INT C/C++ benchmarks and report the
regression percentage ?

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Peter
Collingbourne via llvm-dev
Sent: Tuesday, January 23, 2018 6:45 PM
To: llvm-dev <llvm-dev at lists.llvm.org>
Cc: Vlad Tsyrklevich <vlad at tsyrklevich.net>
Subject: [llvm-dev] 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 if we know that the set of possible branch
targets is fixed (this is sometimes known to be the case when using
whole-program devirtualization or CFI -- see
https://clang.llvm.org/docs/LTOVisibility.html). In that case, we can construct
a so-called “branch funnel” that selects one of the possible targets by
performing a binary search on an address associated with the indirect branch
(for virtual calls, this is the address of the vtable, and for indirect calls
via a function pointer, this is the function pointer itself), eventually
directly branching to the selected target. As a result, the processor is free to
speculatively execute the virtual call, but it can only speculatively branch to
addresses of valid implementations of the virtual function, as opposed to
arbitrary addresses.

For example, suppose that we have the following class hierarchy, which is known
to be closed:

struct Base { virtual void f() = 0; };
struct A : Base { virtual void f(); };
struct B : Base { virtual void f(); };
struct C : Base { virtual void f(); };

We can lay out the vtables for the derived classes in the order A, B, C, and
produce an instruction sequence that directs execution to one of the targets
A::f, B::f and C::f depending on the vtable address. In x86_64 assembly, a
branch funnel would look like this:

lea B::vtable+16(%rip), %r11
cmp %r11, %r10
jb A::f
je B::f
jmp C::f

A caller performs a virtual call by loading the vtable address into register
r10, setting up the other registers for the virtual call and directly calling
the branch funnel as if it were a regular function. Because the branch funnel
enforces control flow integrity by itself, we can also avoid emitting CFI checks
at call sites that use branch funnels when CFI is enabled.

To control the layout of vtables and function pointers, we can extend existing
mechanisms for controlling layout that are used to implement CFI (see
https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html) so that they are
also used whenever a branch funnel needs to be created.

The compiler will only use branch funnels when both the retpoline mitigation
(-mretpoline) and whole-program devirtualization (-fwhole-program-vtables)
features are enabled (the former is on the assumption that in general a regular
indirect call will be less expensive than a branch funnel, and the latter
provides the necessary guarantee that the type hierarchy is closed). Even when
retpolines are enabled, there is still a cost associated with executing a branch
funnel that needs to be balanced against the cost of a regular CFI check and
retpoline, so branch funnels are only used when there are <=10 targets (this
number has not been tuned yet). Because the implementation uses some of the same
mechanisms that are used to implement CFI and whole-program devirtualization, it
requires LTO (it is compatible with both full LTO and ThinLTO).

To measure the performance impact of branch funnels, I ran a selection of Chrome
benchmark suites on Chrome binaries built with CFI, CFI + retpoline and CFI +
retpoline + branch funnels, and measured the median impact over all benchmarks
in each suite. The numbers are presented below. I should preface these numbers
by saying that these are largely microbenchmarks, so the impact of retpoline on
its own is unlikely to be characteristic of real workloads. The numbers to focus
on should be the impact of retpoline + branch funnels relative to the impact of
retpoline, where there is a median 5.7% regression as compared to the median 8%
regression associated with retpoline.


Benchmark suite


CFI + retpoline impact

(relative to CFI)


CFI + retpoline + BF impact

(relative to CFI)


blink_perf.bindings


0.9% improvement


9.8% improvement


blink_perf.dom


20.4% regression


17.5% regression


blink_perf.layout


17.4% regression


14.3% regression


blink_perf.parser


3.8% regression


5.7% regression


blink_perf.svg


8.0% regression


5.4% regression


Future work
Implementation of branch funnels for architectures other than x86_64.

Implementation of branch funnels for indirect calls via a function pointer
(currently only implemented for virtual calls). This will probably require an
implementation of whole-program “devirtualization” for indirect calls.

Use profile data to order the comparisons in the branch funnel by frequency, to
minimise the number of comparisons required for frequent virtual calls.

Thanks,
--
--
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180124/64956794/attachment.html>