linux-kernel - Re: [PATCH] x86/speculation/srbds: do not try to turn mitigation off when not supported

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200615104713.GE14668@zn.tnic>
Date:   Mon, 15 Jun 2020 12:47:13 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Thadeu Lima de Souza Cascardo <cascardo@...onical.com>,
        Mark Gross <mgross@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, Mark Gross <mgross@...ux.intel.com>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        John Johansen <john.johansen@...onical.com>,
        Steve Beattie <sbeattie@...ntu.com>
Subject: Re: [PATCH] x86/speculation/srbds: do not try to turn mitigation off
 when not supported

On Mon, Jun 15, 2020 at 07:27:38AM -0300, Thadeu Lima de Souza Cascardo wrote:
> It was booted without the microcode update. There was microcode available, but
> systems may be booted without it, thus causing warnings due to the MSR
> read/write.

Right.

> That's exactly the fix in the patch I sent, right? Do you want me to resend
> with a comment, then?

Your patch replaced

-       if (srbds_mitigation == SRBDS_MITIGATION_UCODE_NEEDED)

Thinking about this more, I think the proper thing to do is this:

---
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 0b71970d2d3d..ce2931563f8f 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -432,14 +432,14 @@ void update_srbds_msr(void)
 	if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
 		return;
 
-	if (srbds_mitigation == SRBDS_MITIGATION_UCODE_NEEDED)
+	if (srbds_mitigation == SRBDS_MITIGATION_UCODE_NEEDED ||
+	    srbds_mitigation == SRBDS_MITIGATION_TSX_OFF)
 		return;
 
 	rdmsrl(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
 
 	switch (srbds_mitigation) {
 	case SRBDS_MITIGATION_OFF:
-	case SRBDS_MITIGATION_TSX_OFF:
 		mcu_ctrl |= RNGDS_MITG_DIS;
 		break;
 	case SRBDS_MITIGATION_FULL:
---

because looking at:

  7e5b3c267d25 ("x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation")

it says:

    While it is present on all affected CPU models, the microcode mitigation
    is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the
    cases where TSX is not supported or has been disabled with TSX_CTRL.

which could be also understood as "there won't be microcode for those
CPUs and thus MSR_IA32_MCU_OPT_CTRL won't be there."

Because if that is the case, then SRBDS_MITIGATION_TSX_OFF means the MSR
is not there and therefore we should not touch it.

And you've actually shown that without the microcode loaded, you
can have a system which is MDS_NO and which hasn't generated
MSR_IA32_MCU_OPT_CTRL (because the microcode is not loaded) and thus
can't touch said MSR.

Mark?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette