lkml.org 
[lkml]   [2018]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 20/24] x86/speculation: Split out TIF update
On Wed, 21 Nov 2018, Tim Chen wrote:

> On Wed, Nov 21, 2018 at 09:14:50PM +0100, Thomas Gleixner wrote:
> > +static void task_update_spec_tif(struct task_struct *tsk, int tifbit, bool on)
> > {
> > bool update;
> >
> > + if (on)
> > + update = !test_and_set_tsk_thread_flag(tsk, tifbit);
> > + else
> > + update = test_and_clear_tsk_thread_flag(tsk, tifbit);
> > +
> > + /*
> > + * If being set on non-current task, delay setting the CPU
> > + * mitigation until it is scheduled next.
> > + */
> > + if (tsk == current && update)
> > + speculation_ctrl_update_current();
>
> I think all the call paths from prctl and seccomp coming here
> has tsk == current.

We had that discussion before with SSBD:

seccomp_set_mode_filter()
seccomp_attach_filter()
seccomp_sync_threads()
for_each_thread(t)
if (t == current)
continue;
seccomp_assign_mode(t)
arch_seccomp_spec_mitigate(t);

seccomp_assign_mode(current...)
arch_seccomp_spec_mitigate();

> But if task_update_spec_tif gets used in the future where tsk is running
> on a remote CPU, this could lead to the MSR getting out of sync with the
> running task's TIF flag. This will break either performance or security.

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.

Thanks,

tglx

\
 
 \ /
  Last update: 2018-11-23 00:03    [W:0.249 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site