Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp991191imp; Thu, 21 Feb 2019 15:55:08 -0800 (PST) X-Google-Smtp-Source: AHgI3IZB3AoitmOvWNFj0Hg5GTbw4KQmTWorwzR4uG6EBybsz6yt4WHCbdzOMEjLCneFr/kwqEvU X-Received: by 2002:a63:e051:: with SMTP id n17mr1111416pgj.258.1550793308558; Thu, 21 Feb 2019 15:55:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550793308; cv=none; d=google.com; s=arc-20160816; b=OqW3JJSHMZpSMFN+TDypp84hlJm6GyA5O4L9oY8Ft89y6KxwlmFyRZXwUW44nymysw LEMuOpYRPGnku0H+eXS8nG0YFEGPZBVNPN10HMm2etCPcJt1BxwC6Fmcx8yjdT9NJ52Y A5yvJ4LbIj5h6Y9uciqY++q1m9ULJoiRtnZa8TPlmwEyBayYoFfdAH9LdWZhcHG3U+Ec n//Q9ld+FU8/9uEdv0N9yxRbhC/NsxYaT18WcViX8dQ01V8fIS1zTNegB531T/h+BkjV yj1rJ/9x5jjZQwmrhFYEFfB9M59B504XxaFg4MFxBLWT31ddP22jN2713aPie9dftU33 vzdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=ai+qJljkOSM+BNa8+5qAy5ubO6YA1LWKpTMBiUyjPN0=; b=cGwnXwNm/kX38s1JlflRXQzoR/Bv76pyyT7q0hD7/mwmUUaJdMPFqcabSGutnZjYG9 +CDdzvkDFgulGxL8TMEiBCRCmFvOlMb4hPvSlSOSU2ANerSZa1Z2XZCIjQQnr67jVP2P M9HSuP8/Fv5OtS5XqFYnZK+ffhxAhEGcZpHWdWmED5HV+exUZGugtUbenx5Vf1l7HnrS mghDXNRcssySSdANsLtN+4309aG73JxX6b4uF2N4PPn898caGRUzVGqeABuJmMIzpr/h 3QkQp6G1Nayk6fKYoogP29FINbP0Tg8lwlGXUmDko0Yih5/C5MnidZN7sQL4RmztfOgX qqXg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bf6si236060plb.106.2019.02.21.15.54.53; Thu, 21 Feb 2019 15:55:08 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727591AbfBUXwj (ORCPT + 99 others); Thu, 21 Feb 2019 18:52:39 -0500 Received: from mga14.intel.com ([192.55.52.115]:3142 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726841AbfBUXu4 (ORCPT ); Thu, 21 Feb 2019 18:50:56 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2019 15:50:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,397,1544515200"; d="scan'208";a="322394815" Received: from linksys13920.jf.intel.com (HELO rpedgeco-DESK5.jf.intel.com) ([10.54.75.11]) by fmsmga005.fm.intel.com with ESMTP; 21 Feb 2019 15:50:54 -0800 From: Rick Edgecombe To: Andy Lutomirski , Ingo Molnar Cc: linux-kernel@vger.kernel.org, x86@kernel.org, hpa@zytor.com, Thomas Gleixner , Borislav Petkov , Nadav Amit , Dave Hansen , Peter Zijlstra , linux_dti@icloud.com, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, akpm@linux-foundation.org, kernel-hardening@lists.openwall.com, linux-mm@kvack.org, will.deacon@arm.com, ard.biesheuvel@linaro.org, kristen@linux.intel.com, deneen.t.dock@intel.com, Nadav Amit Subject: [PATCH v3 03/20] x86/mm: Save DRs when loading a temporary mm Date: Thu, 21 Feb 2019 15:44:34 -0800 Message-Id: <20190221234451.17632-4-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190221234451.17632-1-rick.p.edgecombe@intel.com> References: <20190221234451.17632-1-rick.p.edgecombe@intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Nadav Amit Prevent user watchpoints from mistakenly firing while the temporary mm is being used. As the addresses that of the temporary mm might overlap those of the user-process, this is necessary to prevent wrong signals or worse things from happening. Cc: Andy Lutomirski Signed-off-by: Nadav Amit --- arch/x86/include/asm/mmu_context.h | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h index d684b954f3c0..0d6c72ece750 100644 --- a/arch/x86/include/asm/mmu_context.h +++ b/arch/x86/include/asm/mmu_context.h @@ -13,6 +13,7 @@ #include #include #include +#include extern atomic64_t last_mm_ctx_id; @@ -358,6 +359,7 @@ static inline unsigned long __get_current_cr3_fast(void) typedef struct { struct mm_struct *prev; + unsigned short bp_enabled : 1; } temp_mm_state_t; /* @@ -380,6 +382,22 @@ static inline temp_mm_state_t use_temporary_mm(struct mm_struct *mm) lockdep_assert_irqs_disabled(); state.prev = this_cpu_read(cpu_tlbstate.loaded_mm); switch_mm_irqs_off(NULL, mm, current); + + /* + * If breakpoints are enabled, disable them while the temporary mm is + * used. Userspace might set up watchpoints on addresses that are used + * in the temporary mm, which would lead to wrong signals being sent or + * crashes. + * + * Note that breakpoints are not disabled selectively, which also causes + * kernel breakpoints (e.g., perf's) to be disabled. This might be + * undesirable, but still seems reasonable as the code that runs in the + * temporary mm should be short. + */ + state.bp_enabled = hw_breakpoint_active(); + if (state.bp_enabled) + hw_breakpoint_disable(); + return state; } @@ -387,6 +405,13 @@ static inline void unuse_temporary_mm(temp_mm_state_t prev) { lockdep_assert_irqs_disabled(); switch_mm_irqs_off(NULL, prev.prev, current); + + /* + * Restore the breakpoints if they were disabled before the temporary mm + * was loaded. + */ + if (prev.bp_enabled) + hw_breakpoint_restore(); } #endif /* _ASM_X86_MMU_CONTEXT_H */ -- 2.17.1