Message ID | ceb2bcdc79f1494151e85734fa7bdc639df275bb.1666651511.git.pawan.kumar.gupta@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp725647wru; Mon, 24 Oct 2022 17:34:37 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7rn9Gw5FAEXr/pq2IRFub490BF50Y/Cax6f2d/JWESXzXp9Wj+9pKoIRMPsrZIECav0A3u X-Received: by 2002:a62:7bc5:0:b0:56b:47ed:22a7 with SMTP id w188-20020a627bc5000000b0056b47ed22a7mr18100002pfc.63.1666658076927; Mon, 24 Oct 2022 17:34:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666658076; cv=none; d=google.com; s=arc-20160816; b=xXaeBUUVmxCLAdct08alI6qruP4vysv0o8WZ39EdyBVYMg4yJpMDnEKYVohFSp9vG1 wjRPiZ296ojl/VonZ7pP/a+ryf54+XexTTXRd1kQwbfJySvmlBUCF0O+9VcHG7pcy6q/ D76QlbkmmrHXCx8sRHdXuqupbWuc2R39np86pg3qabEbSUPdiI5RKD42i0scnvW4Wg3E v21rkM/tN5ojKbAaaQjMv42Kvh+YrY7BZl/Pyy9p9jGc1pix+da1PTYPku3w9Nx6M34p zOHbEc6wp1Dv7hfPQIc0lkqU4SPD57s9O9MaRkUJGmuYA0q6EcUp0E1ssxcDcvzO8vA/ gEew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ft/Jxb2rASN15ajy4VT1XwMRwikbCeKmQiD9qGfgmFY=; b=Xi9kgaxSx3alwh9Fr0Ml6ydQNAA351UxNKUx/Pc8CQGHcG4zRMunPA1l8GZlRTBosn GW+qY5xyTHqZXJ9TG//eTey76hp8iMUfN0WRXyWBj1KwrtMERrNqZ4B8qF61I7L7gdn4 CSSck5qckPgrM2E+0/ZfH1uzMx5Lh2PcGgXNkuKIlzc4kkPjycWqNYPbImShyfNgclY4 ExHfirQfU7xjv4I/P2bw5+aEa+x1+IGUxXF2QNrUcZVAyEu9U103zf5Howho0a9N4eLR Nfbr6T+8NIWBu/WITmuGUdH04LWvN63GF/6T+dTAFRdZYDYvOEj3huvGyE1CHXdF/1i3 V4Bg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=C22EG5Xc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 26-20020a63165a000000b0043895127033si1159398pgw.335.2022.10.24.17.34.23; Mon, 24 Oct 2022 17:34:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=C22EG5Xc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231273AbiJYAds (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Mon, 24 Oct 2022 20:33:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229682AbiJYAdO (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 24 Oct 2022 20:33:14 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF9082BB1E; Mon, 24 Oct 2022 15:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666652294; x=1698188294; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Dg022xT9wrRgqUOEQj0+Hywo+Hdp+CKqSuOIoBjxANA=; b=C22EG5XcyJX2f9Ys6Grt+UBMZlGLH/lCGgd7tZ1gN1686+UC7ougWr99 aIrHkzfS74BbWWuz0Ch+Fdb+qBXcqD2O1oHy+0BMpHJl9ZaYRYZwz16Pt /IBNuH/SgBPSY7gxkAm+dO19oVm9ev8d+Mr0Texj/K9+28FugoE/Kf0mr JFXCkeOWuAlqGL0L87ToRM0OzVfrlqdHNIwYED8UGTK+tI3PwDgi3t+3g xSciMN9ruUD6oYTfGDUSXspM1IbIYMZ3GrZCpQ3BQynOshUa7SnLsxUG/ lPZFlnO4LglySCyrzjRs5lXame45ywF+xnPOe50wc30nNrQlui1ugoyp3 Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="308633276" X-IronPort-AV: E=Sophos;i="5.95,210,1661842800"; d="scan'208";a="308633276" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2022 15:57:56 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="609363407" X-IronPort-AV: E=Sophos;i="5.95,210,1661842800"; d="scan'208";a="609363407" Received: from pkearns-mobl1.amr.corp.intel.com (HELO guptapa-desk.intel.com) ([10.252.131.64]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2022 15:57:56 -0700 From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> To: scott.d.constable@intel.com, daniel.sneddon@linux.intel.com, Jakub Kicinski <kuba@kernel.org>, dave.hansen@intel.com, Johannes Berg <johannes@sipsolutions.net>, Paolo Abeni <pabeni@redhat.com>, antonio.gomez.iglesias@linux.intel.com, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com> Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, gregkh@linuxfoundation.org, netdev@vger.kernel.org Subject: [RFC PATCH 2/2] minstrel_ht: Mitigate BTI gadget minstrel_ht_get_expected_throughput() Date: Mon, 24 Oct 2022 15:57:47 -0700 Message-Id: <ceb2bcdc79f1494151e85734fa7bdc639df275bb.1666651511.git.pawan.kumar.gupta@linux.intel.com> X-Mailer: git-send-email 2.37.3 In-Reply-To: <cover.1666651511.git.pawan.kumar.gupta@linux.intel.com> References: <cover.1666651511.git.pawan.kumar.gupta@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747617659935200504?= X-GMAIL-MSGID: =?utf-8?q?1747617659935200504?= |
Series |
Branch Target Injection (BTI) gadget in minstrel
|
|
Commit Message
Pawan Gupta
Oct. 24, 2022, 10:57 p.m. UTC
Static analysis indicate that indirect target
minstrel_ht_get_expected_throughput() could be used as a disclosure
gadget for Intra-mode Branch Target Injection (IMBTI) and Branch History
Injection (BHI).
ASM generated by compilers indicate a construct of a typical disclosure
gadget, where an adversary-controlled register contents can be used to
transiently access an arbitrary memory location.
Although there are no known ways to exploit this, but to be on safer
side mitigate it by adding a speculation barrier.
Reported-by: Scott D. Constable <scott.d.constable@intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
net/mac80211/rc80211_minstrel_ht.c | 9 +++++++++
1 file changed, 9 insertions(+)
Comments
On Mon, Oct 24, 2022 at 03:57:47PM -0700, Pawan Gupta wrote: > Static analysis indicate that indirect target > minstrel_ht_get_expected_throughput() could be used as a disclosure > gadget for Intra-mode Branch Target Injection (IMBTI) and Branch History > Injection (BHI). You define these new TLAs here, but the code comment below does not, making this code now impossible to understand :( > ASM generated by compilers indicate a construct of a typical disclosure > gadget, where an adversary-controlled register contents can be used to > transiently access an arbitrary memory location. If you have an "adveraray-controlled register contents", why would you waste that on a mere speculation attack and not do something better, like get root instead? > Although there are no known ways to exploit this, but to be on safer > side mitigate it by adding a speculation barrier. > > Reported-by: Scott D. Constable <scott.d.constable@intel.com> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> > --- > net/mac80211/rc80211_minstrel_ht.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c > index 3d91b98db099..7cf90666a865 100644 > --- a/net/mac80211/rc80211_minstrel_ht.c > +++ b/net/mac80211/rc80211_minstrel_ht.c > @@ -11,6 +11,7 @@ > #include <linux/moduleparam.h> > #include <linux/ieee80211.h> > #include <linux/minmax.h> > +#include <linux/nospec.h> > #include <net/mac80211.h> > #include "rate.h" > #include "sta_info.h" > @@ -1999,6 +2000,14 @@ static u32 minstrel_ht_get_expected_throughput(void *priv_sta) > struct minstrel_ht_sta *mi = priv_sta; > int i, j, prob, tp_avg; > > + /* > + * Protect against IMBTI/BHI. This makes no sense here, right? And you are NOT following the proper networking comment style, didn't checkpatch complain about this? > + * > + * Transiently executing this function with an adversary controlled > + * argument may disclose secrets. Speculation barrier prevents that. > + */ > + barrier_nospec(); So how much did you just slow down the normal use of the system? > + > i = MI_RATE_GROUP(mi->max_tp_rate[0]); > j = MI_RATE_IDX(mi->max_tp_rate[0]); These are all internal structures, can't you just bounds-prevent the speculation instead of the hard barrier? thanks, greg k-h
On Tue, Oct 25, 2022 at 09:36:56AM +0200, Greg KH wrote: >On Mon, Oct 24, 2022 at 03:57:47PM -0700, Pawan Gupta wrote: >> Static analysis indicate that indirect target >> minstrel_ht_get_expected_throughput() could be used as a disclosure >> gadget for Intra-mode Branch Target Injection (IMBTI) and Branch History >> Injection (BHI). > >You define these new TLAs here, but the code comment below does not, >making this code now impossible to understand :( I will expand the TLAs in the comment. >> ASM generated by compilers indicate a construct of a typical disclosure >> gadget, where an adversary-controlled register contents can be used to >> transiently access an arbitrary memory location. > >If you have an "adveraray-controlled register contents", why would you >waste that on a mere speculation attack and not do something better, >like get root instead? In the non-transient path those registers can contain system call arguments that are checked for illegal accesses, thus are harmless. But when executing transiently those registers could be interpreted as (completely unrelated) arguments of a disclosure gadget. >> Although there are no known ways to exploit this, but to be on safer >> side mitigate it by adding a speculation barrier. >> >> Reported-by: Scott D. Constable <scott.d.constable@intel.com> >> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> >> --- >> net/mac80211/rc80211_minstrel_ht.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c >> index 3d91b98db099..7cf90666a865 100644 >> --- a/net/mac80211/rc80211_minstrel_ht.c >> +++ b/net/mac80211/rc80211_minstrel_ht.c >> @@ -11,6 +11,7 @@ >> #include <linux/moduleparam.h> >> #include <linux/ieee80211.h> >> #include <linux/minmax.h> >> +#include <linux/nospec.h> >> #include <net/mac80211.h> >> #include "rate.h" >> #include "sta_info.h" >> @@ -1999,6 +2000,14 @@ static u32 minstrel_ht_get_expected_throughput(void *priv_sta) >> struct minstrel_ht_sta *mi = priv_sta; >> int i, j, prob, tp_avg; >> >> + /* >> + * Protect against IMBTI/BHI. > >This makes no sense here, right? I will expand those and add some more explanation. >And you are NOT following the proper networking comment style, didn't >checkpatch complain about this? checkpatch did complain, but I noticed that this file is following regular commenting style everywhere. I can changed that to networking style but it will differ from the rest of the file. >> + * >> + * Transiently executing this function with an adversary controlled >> + * argument may disclose secrets. Speculation barrier prevents that. >> + */ >> + barrier_nospec(); > >So how much did you just slow down the normal use of the system? I don't have data for this. As I understand this function is not called frequently, so perf impact is not expected to be significant. >> + >> i = MI_RATE_GROUP(mi->max_tp_rate[0]); >> j = MI_RATE_IDX(mi->max_tp_rate[0]); > >These are all internal structures, can't you just bounds-prevent the >speculation instead of the hard barrier? The valid bound in this case is large enough (bits 15:6 IIRC) to still pose a risk. As this function is not called frequently adding a speculation barrier looks to be the best choice.
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c index 3d91b98db099..7cf90666a865 100644 --- a/net/mac80211/rc80211_minstrel_ht.c +++ b/net/mac80211/rc80211_minstrel_ht.c @@ -11,6 +11,7 @@ #include <linux/moduleparam.h> #include <linux/ieee80211.h> #include <linux/minmax.h> +#include <linux/nospec.h> #include <net/mac80211.h> #include "rate.h" #include "sta_info.h" @@ -1999,6 +2000,14 @@ static u32 minstrel_ht_get_expected_throughput(void *priv_sta) struct minstrel_ht_sta *mi = priv_sta; int i, j, prob, tp_avg; + /* + * Protect against IMBTI/BHI. + * + * Transiently executing this function with an adversary controlled + * argument may disclose secrets. Speculation barrier prevents that. + */ + barrier_nospec(); + i = MI_RATE_GROUP(mi->max_tp_rate[0]); j = MI_RATE_IDX(mi->max_tp_rate[0]); prob = mi->groups[i].rates[j].prob_avg;