linux-kernel - Re: [patch 20/24] x86/speculation: Split out TIF update

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: <alpine.DEB.2.21.1811262244510.1682@nanos.tec.linutronix.de>
Date:   Mon, 26 Nov 2018 22:55:06 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Tim Chen <tim.c.chen@...ux.intel.com>
cc:     Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jiri Kosina <jkosina@...e.cz>,
        Tom Lendacky <thomas.lendacky@....com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Jon Masters <jcm@...hat.com>,
        Waiman Long <longman9394@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Dave Stewart <david.c.stewart@...el.com>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [patch 20/24] x86/speculation: Split out TIF update

On Mon, 26 Nov 2018, Tim Chen wrote:
> On 11/22/2018 11:37 PM, Ingo Molnar wrote:
> >> We also had that discussion with SSBD and decided that we won't chase
> >> threads and send IPIs around. Yes, it's not perfect, but not the end of the
> >> world either. For PRCTL it's a non issue.
> 
> Looks like seccomp thread can be running on a remote CPU when its
> TIF_SPEC_IB flag gets updated.
>
> I wonder if this will cause STIBP to be always off in this scenario, when
> two tasks with SPEC_IB flags running on a remote CPU have STIBP bit always
> *off* in SPEC MSR.
> 
> Let's say we have tasks A and B running on a remote CPU:
> 
> task A: SPEC_IB flag is on
>
> task B: SPEC_IB flag is off but is currently running on remote CPU, SPEC
>         MSR's STIBP bit is off
>
> Now arch_seccomp_spec_mitigation is called, setting SPEC_IB flag on task B.
> SPEC MSR becomes out of sync with running task B's SPEC_IB flag.
> 
>
> Task B context switches to task A. Because both tasks have SPEC_IB flag
> set and the flag status is unchanged, SPEC MSR's STIBP bit is not
> updated.  SPEC MSR STIBP bit remains off if tasks A and B are the only
> tasks running on the CPU.
>
> There is an equivalent scenario where the SPEC MSR's STIBP bit remains on
> even though both running task A and B's SPEC_IB flags are turned off.
>
> Wonder if I may be missing something so the above scenario is not of
> concern?

The above is real. The question is whether we need to worry about it.

If so, then the right thing to do is to leave thread_info.flags alone and
flip the bits in a shadow storage, e.g. thread_info.spec_flags and after
updating that set something like TIF_SPEC_UPDATE and evaluate that bit on
context switch and if set update the TIF flags. Too tired to code that now,
but it's straight forward. I'll look at it on wednesday if nobody beats me
to it.

Thanks,

	tglx