Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2253457imm; Thu, 7 Jun 2018 07:45:23 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIvlZZoleUjIOxbTroW+E+ZuNcfjsRZGkkcJC5Et8JSZpp4yqfHzVXVQ1wL4KnVZPWCnXyT X-Received: by 2002:a63:744c:: with SMTP id e12-v6mr1874694pgn.4.1528382723296; Thu, 07 Jun 2018 07:45:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528382723; cv=none; d=google.com; s=arc-20160816; b=lDJgbvxIbdGOXnS5X+It3eVr0oUqdsYVgggjbmQzDkgYnHzShsJL8xC0pawdoLkOfH ABwFO5xOKXVMooz+jJ7sxEVF3Brl8ZcR8uXLu+Tx6eYaBa5C23qZr0u/knV9uA/o1WqO AaQIalw3c/7Il7KaOJPE6KIucQ24FAQ0NIgiuYqCnraPHfx69GU10r4za7PKufUvZRTx 7+IvynxJgVyeulkKZWlUP/29bkHkIXMZMIC/dv80B3IOf9wYlSFQMZcKIuwldQf32ERH lNHmEBGZkijJOz0d6rhMmKd9smfmF+zmzJC2tW1aD+QE3naeIpsGjha6OvDC62PQKiG/ jqoA== 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 :arc-authentication-results; bh=+B/Q2GcAN+x3Q2DE6yGvFV/caBSM9FnDnhu1DSRWy5w=; b=SRECvoyT+ocHqOoIrKb55JzRsutkttVk7c3m2x3ib9mOp7Lypfqzn8atvs6W94izf6 XVHmsGVf9VG788e/71fAtEln7pVXJaN3M3mh+G6yV+z3dPvEyhgl5GzcDX8E2waVP7Gm 14vYKo9mGopJuNYV0o2Wh9sDK4428fKkA4fuDn455SCqmnbzpJOwhwpuafuQEyLow50o WGsAFV7ag+RbVJSPSrA7WrmLU9pYeZDwSjKmrFfrxOQZ23dv1ojJe4UV2/GAMUncxJXq Xrb0m2RcM0EwOea5Ltw6TxlCUNfyDhO4XTyJyS87vhHtnvtHmPZkihikE7mKudq68TkA uDKQ== 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 e72-v6si10149692pfd.352.2018.06.07.07.45.08; Thu, 07 Jun 2018 07:45:23 -0700 (PDT) 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 S934872AbeFGOnr (ORCPT + 99 others); Thu, 7 Jun 2018 10:43:47 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:40685 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934145AbeFGOnc (ORCPT ); Thu, 7 Jun 2018 10:43:32 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbw-0005Zq-Sz; Thu, 07 Jun 2018 15:09:57 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvaz-0002l6-K6; Thu, 07 Jun 2018 15:08:57 +0100 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, linux@dominikbrodowski.net, "Tim Chen" , pbonzini@redhat.com, bp@alien8.de, "David Woodhouse" , peterz@infradead.org, gregkh@linux-foundation.org, luto@kernel.org, ak@linux.intel.com, arjan@linux.intel.com, "Thomas Gleixner" , torvalds@linux-foundation.org, karahmed@amazon.de Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 062/410] x86/speculation: Use Indirect Branch Prediction Barrier in context switch In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 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.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Tim Chen commit 18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7 upstream. Flush indirect branches when switching into a process that marked itself non dumpable. This protects high value processes like gpg better, without having too high performance overhead. If done naïvely, we could switch to a kernel idle thread and then back to the original process, such as: process A -> idle -> process A In such scenario, we do not have to do IBPB here even though the process is non-dumpable, as we are switching back to the same process after a hiatus. To avoid the redundant IBPB, which is expensive, we track the last mm user context ID. The cost is to have an extra u64 mm context id to track the last mm we were using before switching to the init_mm used by idle. Avoiding the extra IBPB is probably worth the extra memory for this common scenario. For those cases where tlb_defer_switch_to_init_mm() returns true (non PCID), lazy tlb will defer switch to init_mm, so we will not be changing the mm for the process A -> idle -> process A switch. So IBPB will be skipped for this case. Thanks to the reviewers and Andy Lutomirski for the suggestion of using ctx_id which got rid of the problem of mm pointer recycling. Signed-off-by: Tim Chen Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Cc: ak@linux.intel.com Cc: karahmed@amazon.de Cc: arjan@linux.intel.com Cc: torvalds@linux-foundation.org Cc: linux@dominikbrodowski.net Cc: peterz@infradead.org Cc: bp@alien8.de Cc: luto@kernel.org Cc: pbonzini@redhat.com Cc: gregkh@linux-foundation.org Link: https://lkml.kernel.org/r/1517263487-3708-1-git-send-email-dwmw@amazon.co.uk [bwh: Backported to 3.16: Drop the optimisation for switching via the idle task, since we don't have mm_context_t::ctx_id here] Signed-off-by: Ben Hutchings --- --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -10,6 +10,7 @@ #include #include +#include #include #include #include @@ -100,6 +101,24 @@ void switch_mm_irqs_off(struct mm_struct unsigned cpu = smp_processor_id(); if (likely(prev != next)) { + /* + * Avoid user/user BTB poisoning by flushing the branch + * predictor when switching between processes. This stops + * one process from doing Spectre-v2 attacks on another. + * + * As an optimization, flush indirect branches only when + * switching into processes that disable dumping. This + * protects high value processes like gpg, without having + * too high performance overhead. IBPB is *expensive*! + * + * This will not flush branches when switching into kernel + * threads. It will flush if we switch to a different non- + * dumpable process. + */ + if (tsk && tsk->mm && + get_dumpable(tsk->mm) != SUID_DUMP_USER) + indirect_branch_prediction_barrier(); + this_cpu_write(cpu_tlbstate.state, TLBSTATE_OK); this_cpu_write(cpu_tlbstate.active_mm, next); cpumask_set_cpu(cpu, mm_cpumask(next));