Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp249648pxx; Wed, 28 Oct 2020 04:05:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsao/jt4MfObleVbttbSbB6+ZBifXpqjrXbxj+50PCsl3Sx0GqCFB1DUcerbzUylu4zyES X-Received: by 2002:a17:906:bfe2:: with SMTP id vr2mr7217690ejb.248.1603883132204; Wed, 28 Oct 2020 04:05:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603883132; cv=none; d=google.com; s=arc-20160816; b=krwomHHs3sHTOAI0ISkGCWpnYdNE4cTQV0HYf8UNDR1kW4Hbov+xQulyC/sXm5KmAq wHgyeuAgGgMNng2ITU1pQHxn4Wo0p8bSwW5MD+a7pCMIrgbA1xG9VV7SK4V0ohCyRjKX Yux7x77lc0EFm7ndxY8WWZfjTNv3u5XItKOCblTswTjhQ4HjvSeRw8Bddjwiq+095TJ6 LSxmbOyLJ20IS2W/qHOruEZliEaH2PfwO6pbL5NG578HC6kQhYA+cmVRKk57HMyKAaTm 758rxN0D+fe35zZs9y5r1pjZMmIVl95HxLNFhLh6ZvwBJtaMTjyUqIHLE2fNhmTxLU87 DoQw== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=JV2CIihyVY33u59vXwOx3k4/8AFp6E7k5ZhjowJ13GQ=; b=HQYsWMJ0YaiM4eWFV4wjAgbnUFhtBwlVQ2bYEXaR5M23lxwKInsOABnzLEb6/E5eRU uV5dgxLuY3lAaB8g3VuTA5HLqU68FFPcPMP5rIe92WKnUNNQRKecrsnFRXU6Im1o374w bq9e8ODBAttmYVwTnMYR4TLOc2Gq20UL5AvvjxARrir3/aCmbptKYMnrXuErrO000N2o JR2oDSlxogTHCe6QbkF41Fo5F4nMpXB+JtDOM/C22jMEigeDAkUHtd4xcMIVBkwWIg/9 EKFh9qZYMla1aZ4kse4tIV6lKYeF2VA57GMIG7q5A8NMgjpS6wl7+F5oULrK9Mrjt8zr ILYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="Bcf/lYs2"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t1si2868715ejb.712.2020.10.28.04.05.08; Wed, 28 Oct 2020 04:05:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="Bcf/lYs2"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1784966AbgJ0O7n (ORCPT + 99 others); Tue, 27 Oct 2020 10:59:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:44030 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762711AbgJ0OoM (ORCPT ); Tue, 27 Oct 2020 10:44:12 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D8283206B2; Tue, 27 Oct 2020 14:44:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603809850; bh=IPBo/Bxj09puXFIl59GtLe4cG85zd4UoaUO4FnwU42s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Bcf/lYs2xLQOdpXIOnRZZosW3XZgiiMCd1fx2rqJNK0CO/4m76HFAdsijd1gByudU k7KkaFrsFhzILLScvg8YFmtghe234tGf3+Cue6djMJXHVsIpnbXK63KFoH0SCwZmhD tk9XgiD9d5MmYkFl6A7TkulNm+CCIRiwZ+qSCDAQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andy Lutomirski , Peter Zijlstra , kernel test robot , Borislav Petkov , Tony Luck , Sasha Levin Subject: [PATCH 5.4 341/408] x86/mce: Make mce_rdmsrl() panic on an inaccessible MSR Date: Tue, 27 Oct 2020 14:54:39 +0100 Message-Id: <20201027135510.844967668@linuxfoundation.org> X-Mailer: git-send-email 2.29.1 In-Reply-To: <20201027135455.027547757@linuxfoundation.org> References: <20201027135455.027547757@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Borislav Petkov [ Upstream commit e2def7d49d0812ea40a224161b2001b2e815dce2 ] If an exception needs to be handled while reading an MSR - which is in most of the cases caused by a #GP on a non-existent MSR - then this is most likely the incarnation of a BIOS or a hardware bug. Such bug violates the architectural guarantee that MCA banks are present with all MSRs belonging to them. The proper fix belongs in the hardware/firmware - not in the kernel. Handling an #MC exception which is raised while an NMI is being handled would cause the nasty NMI nesting issue because of the shortcoming of IRET of reenabling NMIs when executed. And the machine is in an #MC context already so be at its side. Tracing MSR accesses while in #MC is another no-no due to tracing being inherently a bad idea in atomic context: vmlinux.o: warning: objtool: do_machine_check()+0x4a: call to mce_rdmsrl() leaves .noinstr.text section so remove all that "additional" functionality from mce_rdmsrl() and provide it with a special exception handler which panics the machine when that MSR is not accessible. The exception handler prints a human-readable message explaining what the panic reason is but, what is more, it panics while in the #GP handler and latter won't have executed an IRET, thus opening the NMI nesting issue in the case when the #MC has happened while handling an NMI. (#MC itself won't be reenabled until MCG_STATUS hasn't been cleared). Suggested-by: Andy Lutomirski Suggested-by: Peter Zijlstra [ Add missing prototypes for ex_handler_* ] Reported-by: kernel test robot Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Link: https://lkml.kernel.org/r/20200906212130.GA28456@zn.tnic Signed-off-by: Sasha Levin --- arch/x86/kernel/cpu/mce/core.c | 72 +++++++++++++++++++++++++----- arch/x86/kernel/cpu/mce/internal.h | 10 +++++ 2 files changed, 70 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c index fd76e3733dd3d..92331de16d70e 100644 --- a/arch/x86/kernel/cpu/mce/core.c +++ b/arch/x86/kernel/cpu/mce/core.c @@ -388,10 +388,28 @@ static int msr_to_offset(u32 msr) return -1; } +__visible bool ex_handler_rdmsr_fault(const struct exception_table_entry *fixup, + struct pt_regs *regs, int trapnr, + unsigned long error_code, + unsigned long fault_addr) +{ + pr_emerg("MSR access error: RDMSR from 0x%x at rIP: 0x%lx (%pS)\n", + (unsigned int)regs->cx, regs->ip, (void *)regs->ip); + + show_stack_regs(regs); + + panic("MCA architectural violation!\n"); + + while (true) + cpu_relax(); + + return true; +} + /* MSR access wrappers used for error injection */ static u64 mce_rdmsrl(u32 msr) { - u64 v; + DECLARE_ARGS(val, low, high); if (__this_cpu_read(injectm.finished)) { int offset = msr_to_offset(msr); @@ -401,21 +419,43 @@ static u64 mce_rdmsrl(u32 msr) return *(u64 *)((char *)this_cpu_ptr(&injectm) + offset); } - if (rdmsrl_safe(msr, &v)) { - WARN_ONCE(1, "mce: Unable to read MSR 0x%x!\n", msr); - /* - * Return zero in case the access faulted. This should - * not happen normally but can happen if the CPU does - * something weird, or if the code is buggy. - */ - v = 0; - } + /* + * RDMSR on MCA MSRs should not fault. If they do, this is very much an + * architectural violation and needs to be reported to hw vendor. Panic + * the box to not allow any further progress. + */ + asm volatile("1: rdmsr\n" + "2:\n" + _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_rdmsr_fault) + : EAX_EDX_RET(val, low, high) : "c" (msr)); - return v; + + return EAX_EDX_VAL(val, low, high); +} + +__visible bool ex_handler_wrmsr_fault(const struct exception_table_entry *fixup, + struct pt_regs *regs, int trapnr, + unsigned long error_code, + unsigned long fault_addr) +{ + pr_emerg("MSR access error: WRMSR to 0x%x (tried to write 0x%08x%08x) at rIP: 0x%lx (%pS)\n", + (unsigned int)regs->cx, (unsigned int)regs->dx, (unsigned int)regs->ax, + regs->ip, (void *)regs->ip); + + show_stack_regs(regs); + + panic("MCA architectural violation!\n"); + + while (true) + cpu_relax(); + + return true; } static void mce_wrmsrl(u32 msr, u64 v) { + u32 low, high; + if (__this_cpu_read(injectm.finished)) { int offset = msr_to_offset(msr); @@ -423,7 +463,15 @@ static void mce_wrmsrl(u32 msr, u64 v) *(u64 *)((char *)this_cpu_ptr(&injectm) + offset) = v; return; } - wrmsrl(msr, v); + + low = (u32)v; + high = (u32)(v >> 32); + + /* See comment in mce_rdmsrl() */ + asm volatile("1: wrmsr\n" + "2:\n" + _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_fault) + : : "c" (msr), "a"(low), "d" (high) : "memory"); } /* diff --git a/arch/x86/kernel/cpu/mce/internal.h b/arch/x86/kernel/cpu/mce/internal.h index 43031db429d24..231954fe5b4e6 100644 --- a/arch/x86/kernel/cpu/mce/internal.h +++ b/arch/x86/kernel/cpu/mce/internal.h @@ -172,4 +172,14 @@ extern bool amd_filter_mce(struct mce *m); static inline bool amd_filter_mce(struct mce *m) { return false; }; #endif +__visible bool ex_handler_rdmsr_fault(const struct exception_table_entry *fixup, + struct pt_regs *regs, int trapnr, + unsigned long error_code, + unsigned long fault_addr); + +__visible bool ex_handler_wrmsr_fault(const struct exception_table_entry *fixup, + struct pt_regs *regs, int trapnr, + unsigned long error_code, + unsigned long fault_addr); + #endif /* __X86_MCE_INTERNAL_H__ */ -- 2.25.1