Re: [RFC PATCH 0/2] Branch Target Injection (BTI) gadget in minstrel
From: Pawan Gupta
Date: Tue Oct 25 2022 - 15:39:00 EST
On Tue, Oct 25, 2022 at 01:07:52PM +0200, Peter Zijlstra wrote:
On Mon, Oct 24, 2022 at 03:57:45PM -0700, Pawan Gupta wrote:
The other goal of this series is to start a discussion on whether such
hard to exploit, but theoretical possible attacks deems to be mitigated.
In general Branch Target Injection class of attacks involves an adversary
controlling an indirect branch target to misspeculate to a disclosure gadget.
For a successful attack an adversary also needs to control the register
contents used by the disclosure gadget.
I'm thinking this is going about it wrong. You're going to be randomly
sprinking LFENCEs around forever if you go down this path making stuff
slower and slower.
Right, an alternative to LFENCE is to mask the indexes(wherever
possible) for gadgets that are called frequently. But still its not a
clean solution.
Not to mention that it's going to bitrot; the function might change but
the LFENCE will stay, protecting nothing but still being slow.
Totally agree with this.
I think the focus should be on finding the source sites, not protecting
the target sites. Where can an attacker control the register content and
have an indirect jump/call.
That is an interesting approach. I am wondering what mitigation can
be applied at source? LFENCE before an indirect branch can greatly
reduce the speculation window, but will not completely eliminate it.
Also LFENCE at sources could be costlier than masking the indexes at
targets or LFENCE at the targets.
Also, things like FineIBT will severely limit the viability of all this.
Yes.
And how is sprinking random LFENCEs around better than running with
spectre_v2=eibrs,retpoline which is the current recommended mitigation
against all this IIRC (or even eibrs,lfence for lesser values of
paranoia).
Its a trade-off between performance and spot fixing (hopefully handful
of) gadgets. Even the gadget in question here is not demonstrated to be
exploitable. If this scenario changes, polluting the kernel all over is
definitely not the right approach.