linux-kernel - Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

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: <20180201082518.w3bk5udvzdre7zc2@gmail.com>
Date:   Thu, 1 Feb 2018 09:25:20 +0100
From:   Christian Brauner <christian.brauner@...onical.com>
To:     Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     mingo@...nel.org, hpa@...or.com, tim.c.chen@...ux.intel.com,
        dwmw@...zon.co.uk, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, jpoimboe@...hat.com
Subject: Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction
 Barrier in context switch

On Wed, Jan 31, 2018 at 08:03:00AM +0100, Dominik Brodowski wrote:
> On Tue, Jan 30, 2018 at 02:39:45PM -0800, tip-bot for Tim Chen wrote:
> > Commit-ID:  18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7
> > Gitweb:     https://git.kernel.org/tip/18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7
> > Author:     Tim Chen <tim.c.chen@...ux.intel.com>
> > AuthorDate: Mon, 29 Jan 2018 22:04:47 +0000
> > Committer:  Thomas Gleixner <tglx@...utronix.de>
> > CommitDate: Tue, 30 Jan 2018 23:09:21 +0100
> > 
> > x86/speculation: Use Indirect Branch Prediction Barrier in context switch
> > 
> > Flush indirect branches when switching into a process that marked itself
> > non dumpable. This protects high value processes like gpg better,
> > without having too high performance overhead.
> 
> For the record, I am still opposed to limit this to non-dumpable processes.
> Whether a process needs protection by IBPB on context switches is a
> different question to whether a process should be allowed to be dumped,

This is especially true since you can get into a non-dumpable state
implicitly due to setuid() in a new user namespace. So avoiding the
performance hit due to IBPD is not necessary a concious decision taken
by calling prctl(), that is to say even if you care about performance
and don't want to take the IBPB hit you might accidently have to take it
when doing a setuid(). Also there are definitely workloads where
you want to be able to ptrace a task while at the same time having it do
IBPB. So let's not limit this to non-dumpable taks! Thanks Dominik!

> though the former may be a superset of the latter. In my opinion, IBPB
> should be enabled on all context switches to userspace processes, until we
> have a clear mitigation strategy for userspace against Spectre-v2 designed
> and implemented.
> 
> Thanks,
> 	Dominik
> 
> --------------------------
> From: Dominik Brodowski <linux@...inikbrodowski.net>
> Date: Wed, 31 Jan 2018 07:43:12 +0100
> Subject: [PATCH] x86/speculation: Do not limit Indirect Branch Prediction Barrier to non-dumpable processes
> 
> Whether a process needs protection by IBPB on context switches is a
> different question to whether a process should be allowed to be dumped,
> though the former may be a superset of the latter. Enable IBPB on all
> context switches to a different userspace process, until we have a clear
> mitigation strategy for userspace against Spectre-v2 designed and
> implemented.

Thanks Dominik. That makes a lot more sense!

> 
> Signed-off-by: Dominik Brodowski <linux@...inikbrodowski.net>
> 
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 012d02624848..f54897b68b16 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -255,19 +255,13 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
>  		 * predictor when switching between processes. This stops
>  		 * one process from doing Spectre-v2 attacks on another.
>  		 *
> -		 * As an optimization, flush indirect branches only when
> -		 * switching into processes that disable dumping. This
> -		 * protects high value processes like gpg, without having
> -		 * too high performance overhead. IBPB is *expensive*!
> -		 *
>  		 * This will not flush branches when switching into kernel
>  		 * threads. It will also not flush if we switch to idle
>  		 * thread and back to the same process. It will flush if we
> -		 * switch to a different non-dumpable process.
> +		 * switch to a different user process.
>  		 */
>  		if (tsk && tsk->mm &&
> -		    tsk->mm->context.ctx_id != last_ctx_id &&
> -		    get_dumpable(tsk->mm) != SUID_DUMP_USER)
> +		    tsk->mm->context.ctx_id != last_ctx_id)
>  			indirect_branch_prediction_barrier();
>  
>  		if (IS_ENABLED(CONFIG_VMAP_STACK)) {