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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200615102738.GZ4342@mussarela>
Date:   Mon, 15 Jun 2020 07:27:38 -0300
From:   Thadeu Lima de Souza Cascardo <cascardo@...onical.com>
To:     Borislav Petkov <bp@...en8.de>
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 10:28:58AM +0200, Borislav Petkov wrote:
> On Tue, Jun 09, 2020 at 02:43:13PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > When SRBDS is mitigated by TSX OFF, update_srbds_msr will still read and
> 
> Are you talking about this case in srbds_select_mitigation():
> 
>         if ((ia32_cap & ARCH_CAP_MDS_NO) && !boot_cpu_has(X86_FEATURE_RTM))
>                 srbds_mitigation = SRBDS_MITIGATION_TSX_OFF;
> 
> ?
> 

That's the case that it hits, correct.

> and you have a system which:
> 
>          * Check to see if this is one of the MDS_NO systems supporting
>          * TSX that are only exposed to SRBDS when TSX is enabled.
> 
> i.e., no SRBDS microcode for it and the fix is to disable TSX?

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.

> 
> If so, I think the right fix should be to do:
> 
> 	if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL))
> 		return;
> 
> in update_srbds_msr() with a comment above it explaining why that check
> is being done.

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

Thanks.
Cascardo.

> 
> Hmmm.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette