Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c27de92c10d05891bc804fe0b955c7428ec534dd.camel@sipsolutions.net>
Subject: Re: [RFC PATCH 0/2] Branch Target Injection (BTI) gadget in minstrel
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>
Cc:     scott.d.constable@intel.com, daniel.sneddon@linux.intel.com,
        Jakub Kicinski <kuba@kernel.org>, dave.hansen@intel.com,
        Paolo Abeni <pabeni@redhat.com>,
        antonio.gomez.iglesias@linux.intel.com,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
        x86@kernel.org, gregkh@linuxfoundation.org, netdev@vger.kernel.org
Date:   Tue, 25 Oct 2022 21:56:21 +0200
In-Reply-To: <20221025193845.z7obsqotxi2yiwli@desk>
References: <cover.1666651511.git.pawan.kumar.gupta@linux.intel.com>
         <Y1fDiJtxTe8mtBF8@hirez.programming.kicks-ass.net>
         <20221025193845.z7obsqotxi2yiwli@desk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) 
MIME-Version: 1.0
Precedence: bulk

On Tue, 2022-10-25 at 12:38 -0700, Pawan Gupta wrote:
>=20
> > And how is sprinking random LFENCEs around better than running with
> > spectre_v2=3Deibrs,retpoline which is the current recommended mitigatio=
n
> > against all this IIRC (or even eibrs,lfence for lesser values of
> > paranoia).
>=20
> 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.
>=20
Btw, now I'm wondering - you were detecting these with the compiler
based something, could there be a compiler pass to insert appropriate
things, perhaps as a gcc plugin or something?

Now honestly I have no idea if it's feasible, but since you're detecting
it that way, and presumably then we'd have to maintain the detection and
run it regularly to make sure that (a) things didn't bitrot and the
gadget is still there, and (b) no new places show up ... perhaps the
better way would be to combine both?

johannes