[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b4a64b97-32d2-d83d-9146-ebc9a4cc9ff6@intel.com>
Date: Tue, 25 Oct 2022 15:00:35 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Peter Zijlstra <peterz@...radead.org>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Cc: scott.d.constable@...el.com, daniel.sneddon@...ux.intel.com,
Jakub Kicinski <kuba@...nel.org>,
Johannes Berg <johannes@...solutions.net>,
Paolo Abeni <pabeni@...hat.com>,
antonio.gomez.iglesias@...ux.intel.com,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
x86@...nel.org, gregkh@...uxfoundation.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Branch Target Injection (BTI) gadget in minstrel
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.
Powered by blists - more mailing lists