linux-kernel - [tip: ras/core] x86/MCE: Check a hw error's address to determine proper recovery action

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <168423292833.404.13379284574944485895.tip-bot2@tip-bot2>
Date:   Tue, 16 May 2023 10:28:48 -0000
From:   "tip-bot2 for Yazen Ghannam" <tip-bot2@...utronix.de>
To:     linux-tip-commits@...r.kernel.org
Cc:     Yazen Ghannam <yazen.ghannam@....com>,
        "Borislav Petkov (AMD)" <bp@...en8.de>,
        Tony Luck <tony.luck@...el.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: [tip: ras/core] x86/MCE: Check a hw error's address to determine
 proper recovery action

The following commit has been merged into the ras/core branch of tip:

Commit-ID:     e40879b6d7d858b03813cd53c17dfef9c297f525
Gitweb:        https://git.kernel.org/tip/e40879b6d7d858b03813cd53c17dfef9c297f525
Author:        Yazen Ghannam <yazen.ghannam@....com>
AuthorDate:    Fri, 08 Jan 2021 04:00:35 
Committer:     Borislav Petkov (AMD) <bp@...en8.de>
CommitterDate: Tue, 16 May 2023 12:16:22 +02:00

x86/MCE: Check a hw error's address to determine proper recovery action

Make sure that machine check errors with a usable address are properly
marked as poison.

This is needed for errors that occur on memory which have
MCG_STATUS[RIPV] clear - i.e., the interrupted process cannot be
restarted reliably. One example is data poison consumption through the
instruction fetch units on AMD Zen-based systems.

The MF_MUST_KILL flag is passed to memory_failure() when
MCG_STATUS[RIPV] is not set. So the associated process will still be
killed.  What this does, practically, is get rid of one more check to
kill_current_task with the eventual goal to remove it completely.

Also, make the handling identical to what is done on the notifier path
(uc_decode_notifier() does that address usability check too).

The scenario described above occurs when hardware can precisely identify
the address of poisoned memory, but execution cannot reliably continue
for the interrupted hardware thread.

  [ bp: Massage commit message. ]

Signed-off-by: Yazen Ghannam <yazen.ghannam@....com>
Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
Reviewed-by: Tony Luck <tony.luck@...el.com>
Link: https://lore.kernel.org/r/20230322005131.174499-1-tony.luck@intel.com
---
 arch/x86/kernel/cpu/mce/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 2eec60f..22dfcb2 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1533,7 +1533,7 @@ noinstr void do_machine_check(struct pt_regs *regs)
 		/* If this triggers there is no way to recover. Die hard. */
 		BUG_ON(!on_thread_stack() || !user_mode(regs));

-		if (kill_current_task)
+		if (!mce_usable_address(&m))
 			queue_task_work(&m, msg, kill_me_now);
 		else
 			queue_task_work(&m, msg, kill_me_maybe);