mbox series

[RFC,0/2] Branch Target Injection (BTI) gadget in minstrel

Message ID cover.1666651511.git.pawan.kumar.gupta@linux.intel.com
Headers show
Series Branch Target Injection (BTI) gadget in minstrel | expand

Message

Pawan Gupta Oct. 24, 2022, 10:57 p.m. UTC 
Hi,

There is a theoretical possibility of using
minstrel_ht_get_expected_throughput() as a disclosure gadget for Branch
History Injection (BHI)/Intra-mode Branch Target Injection (IMBTI) [1].
Requesting feedback on the couple of patches that mitigates this.

First patch adds a generic speculation barrier. Second patch uses the
speculation barrier to mitigate BHI/IMBTI.

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.

Assuming preconditions are met, a disclosure gadget would transiently do
below:

  1. Loads an attacker chosen data from memory.
  2. Based on the data, modifies cache state that is observable by an attacker.

Although both these operations are architecturally invisible, the cache state
changes could be used to infer the data.

Disclosure gadget is mitigated by adding a speculation barrier.

Thanks,
Pawan

[1] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html

Pawan Gupta (2):
  nospec: Add a generic barrier_nospec()
  minstrel_ht: Mitigate BTI gadget minstrel_ht_get_expected_throughput()

 include/linux/nospec.h             | 4 ++++
 net/mac80211/rc80211_minstrel_ht.c | 9 +++++++++
 2 files changed, 13 insertions(+)

Comments

Dave Hansen Oct. 25, 2022, 10 p.m. UTC | #1 
On 10/25/22 04:07, Peter Zijlstra wrote:
> 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.

How would this work with something like 'struct file_operations' which
provide a rich set of indirect calls that frequently have fully
user-controlled values in registers?

It certainly wouldn't *hurt* to be zeroing out the registers that are
unused at indirect call sites.  But, the majority of gadgets in this
case used rdi and rsi, which are the least likely to be able to be
zapped at call sites.