Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3336755imu; Sun, 11 Nov 2018 12:39:59 -0800 (PST) X-Google-Smtp-Source: AJdET5eo/CNhWw5QVfMtYz/kayYQ23BNF1X176knyuQAIxXo+/o3vGNDJbms0sfn8FYObf6axY8m X-Received: by 2002:a17:902:187:: with SMTP id b7-v6mr17443014plb.150.1541968799271; Sun, 11 Nov 2018 12:39:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541968799; cv=none; d=google.com; s=arc-20160816; b=bsDjwh4oTmZS4pdKLhLOhezkrJTP8aoGQNOhiFDpjFdscApYfbMgfzu4z26k76LpzK vfZWRDz3HWYlRrkLAlUoPjAWrVInu7GW/2k6R8hcjboOR4Yr+/a8cYMM21gPAgQNlfCk NHKAAyPYtpdk19da8MEzqhoYDyvLfURFM+CrziBtB6PoZrlu8v5oCMzjy/P+MQ73hFEu ZjKUDXFWZB47nSG2ZE+aS8pDOd48lW6cYGZW1C7ztrn1jjAR/9Q3yfgWrfmGIIHmKh2J JyA+vj+aoZZ3/X9qLh9GO7855hok/D+54/9EClEOqkprcvvAVAuWmIH0YrrxpvZjxU56 Fcjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=n9PQ0JIVpNE6mjl3CKrtPJgGi6xy7uzdPX08cCXx8Og=; b=cCn5znOMV6nEpm/j5SzHUXcmuGhHOUhsTf8S69aRN1x7XNsxVJwsI5g9QWElejtV18 znCsoRZXhQcWaafq+ynh/Re3NRCcusb7KTNQv4kdMxzp7KlUIWpfPEGI/9mbmPpzIyxq K3w3wIcLjYmf0kXHoiKe9+4Ckslzfl40PrCGR8lFLtkrb5YPMNF56AD5dBdYUDrQBsZZ 4yFnhl6nd5Hw26RDOXmKjN2nuzTGaUwNsLAxfxDoN7sdZ7yVFB9/ybWTp0Sq8XEacMDr 3Y6iBXxC/zdqpAoWDudjwmqtN31/XHymcz9ELScpbK7cx0dzfVsCIH9TJ4J9Cvfqd2ro QoNg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t3-v6si16226645pfa.170.2018.11.11.12.39.44; Sun, 11 Nov 2018 12:39:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730007AbeKLFsI (ORCPT + 99 others); Mon, 12 Nov 2018 00:48:08 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49532 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729978AbeKLFsH (ORCPT ); Mon, 12 Nov 2018 00:48:07 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvsT-0000oU-BS; Sun, 11 Nov 2018 19:58:37 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsS-0001aT-VP; Sun, 11 Nov 2018 19:58:36 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Peter Zijlstra" , "Linus Torvalds" , "Mark Rutland" , "Ingo Molnar" , "Dan Williams" , "Thomas Gleixner" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 160/366] x86/spectre_v1: Disable compiler optimizations over array_index_mask_nospec() In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Dan Williams commit eab6870fee877258122a042bfd99ee7908c40280 upstream. Mark Rutland noticed that GCC optimization passes have the potential to elide necessary invocations of the array_index_mask_nospec() instruction sequence, so mark the asm() volatile. Mark explains: "The volatile will inhibit *some* cases where the compiler could lift the array_index_nospec() call out of a branch, e.g. where there are multiple invocations of array_index_nospec() with the same arguments: if (idx < foo) { idx1 = array_idx_nospec(idx, foo) do_something(idx1); } < some other code > if (idx < foo) { idx2 = array_idx_nospec(idx, foo); do_something_else(idx2); } ... since the compiler can determine that the two invocations yield the same result, and reuse the first result (likely the same register as idx was in originally) for the second branch, effectively re-writing the above as: if (idx < foo) { idx = array_idx_nospec(idx, foo); do_something(idx); } < some other code > if (idx < foo) { do_something_else(idx); } ... if we don't take the first branch, then speculatively take the second, we lose the nospec protection. There's more info on volatile asm in the GCC docs: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile " Reported-by: Mark Rutland Signed-off-by: Dan Williams Acked-by: Mark Rutland Acked-by: Thomas Gleixner Acked-by: Linus Torvalds Cc: Peter Zijlstra Fixes: babdde2698d4 ("x86: Implement array_index_mask_nospec") Link: https://lkml.kernel.org/lkml/152838798950.14521.4893346294059739135.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings --- arch/x86/include/asm/barrier.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/include/asm/barrier.h +++ b/arch/x86/include/asm/barrier.h @@ -38,7 +38,7 @@ static inline unsigned long array_index_ { unsigned long mask; - asm ("cmp %1,%2; sbb %0,%0;" + asm volatile ("cmp %1,%2; sbb %0,%0;" :"=r" (mask) :"g"(size),"r" (index) :"cc");