linux-kernel - Re: [Patch v4 17/18] x86/speculation: Update SPEC

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.1811052326040.1659@nanos.tec.linutronix.de>
Date:   Tue, 6 Nov 2018 00:04:34 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Tim Chen <tim.c.chen@...ux.intel.com>
cc:     Jiri Kosina <jikos@...nel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        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>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Kees Cook <keescook@...omium.org>
Subject: Re: [Patch v4 17/18] x86/speculation: Update SPEC_CTRL MSRs of remote
 CPUs

Tim,

On Mon, 5 Nov 2018, Tim Chen wrote:
> How about sending an IPI if a remote CPU needs to have its SPEC_CTRL MSR
> updated?
> 
> Something like the following to replace this patch?

...

> +static void spec_ctrl_update_func(void *info)
> +{
> +	speculation_ctrl_update(task_thread_info(current)->flags);
> +}
> +
>  static void set_task_stibp(struct task_struct *tsk, bool stibp_on)
>  {
>  	bool update = false;
> +	int cpu;
>  
>  	if (!static_branch_unlikely(&spectre_v2_app_lite))
>  		return;
> @@ -789,6 +795,12 @@ static void set_task_stibp(struct task_struct *tsk, bool stibp_on)
>  
>  	if (tsk == current)
>  		speculation_ctrl_update_current();
> +	else {
> +		cpu = task_cpu(tsk);
> +		if (cpu != smp_processor_id())
> +			smp_call_function_single(cpu, spec_ctrl_update_func,
> +						 NULL, false); 
> +	}


Aside of the condition being pointless in that case, that issues an IPI
whether the task is running or not. So this allows a task to issue tons of
async IPIs disturbing others by toggling the control.

I'm less and less convinced that piggybacking this on dumpable is a good
idea. It's lots of extra code and the security people are not really happy
about the whole thing either.

Can we please start out with the SSBD model and make use of the PRCTL and
the seccomp mitigation control?

Kees?

Thanks,

	tglx