On Tue, 27 Nov 2018, Tim Chen wrote:
> On 11/27/2018 02:36 PM, Thomas Gleixner wrote:
> >> We need this special handling only if the next task has TIF_SPEC_UPDATE
> >> set, which is one-off event globally (when seccomp marks all its threads
> >> so due to seccomp filter change), and once all the
On Tue, 27 Nov 2018, Tim Chen wrote:
> On 11/27/2018 02:36 PM, Thomas Gleixner wrote:
> >> We need this special handling only if the next task has TIF_SPEC_UPDATE
> >> set, which is one-off event globally (when seccomp marks all its threads
> >> so due to seccomp filter change), and once all the
On Tue, 27 Nov 2018, Thomas Gleixner wrote:
> > Does it really have to?
> >
> > We need this special handling only if the next task has TIF_SPEC_UPDATE
> > set, which is one-off event globally (when seccomp marks all its threads
> > so due to seccomp filter change), and once all the
On Tue, 27 Nov 2018, Thomas Gleixner wrote:
> > Does it really have to?
> >
> > We need this special handling only if the next task has TIF_SPEC_UPDATE
> > set, which is one-off event globally (when seccomp marks all its threads
> > so due to seccomp filter change), and once all the
On 11/27/2018 02:36 PM, Thomas Gleixner wrote:
>>
>> We need this special handling only if the next task has TIF_SPEC_UPDATE
>> set, which is one-off event globally (when seccomp marks all its threads
>> so due to seccomp filter change), and once all the TIF_SPEC_UPDATE tasks
>> schedule at
On 11/27/2018 02:36 PM, Thomas Gleixner wrote:
>>
>> We need this special handling only if the next task has TIF_SPEC_UPDATE
>> set, which is one-off event globally (when seccomp marks all its threads
>> so due to seccomp filter change), and once all the TIF_SPEC_UPDATE tasks
>> schedule at
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> On Tue, 27 Nov 2018, Thomas Gleixner wrote:
>
> > > static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > > index 3f5e351bdd37..6c4fcef52b19 100644
> > > ---
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> On Tue, 27 Nov 2018, Thomas Gleixner wrote:
>
> > > static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > > index 3f5e351bdd37..6c4fcef52b19 100644
> > > ---
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> > > static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > > index 3f5e351bdd37..6c4fcef52b19 100644
> > > --- a/arch/x86/kernel/process.c
> > > +++
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> > > static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > > index 3f5e351bdd37..6c4fcef52b19 100644
> > > --- a/arch/x86/kernel/process.c
> > > +++
On Tue, 27 Nov 2018, Thomas Gleixner wrote:
> > static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > index 3f5e351bdd37..6c4fcef52b19 100644
> > --- a/arch/x86/kernel/process.c
> > +++
On Tue, 27 Nov 2018, Thomas Gleixner wrote:
> > static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
> > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > index 3f5e351bdd37..6c4fcef52b19 100644
> > --- a/arch/x86/kernel/process.c
> > +++
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> struct thread_info {
> unsigned long flags; /* low level flags */
> + unsigned long spec_flags; /* spec flags to sync on ctxsw
> */
The information is already available in task->atomic_flags, no need for new
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> struct thread_info {
> unsigned long flags; /* low level flags */
> + unsigned long spec_flags; /* spec flags to sync on ctxsw
> */
The information is already available in task->atomic_flags, no need for new
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -474,6 +474,21 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
> task_struct *next_p)
>
> tifn = READ_ONCE(task_thread_info(next_p)->flags);
> tifp =
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -474,6 +474,21 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
> task_struct *next_p)
>
> tifn = READ_ONCE(task_thread_info(next_p)->flags);
> tifp =
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> > That's racy and does not prevent the situation because the TIF flags are
> > updated befor the UPDATE bit is set.
>
> > So __speculation_ctrl_update() might see the new bits, but not
> > TIF_SPEC_UPDATE.
>
> Hm, right, scratch that. We'd need to do
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> > That's racy and does not prevent the situation because the TIF flags are
> > updated befor the UPDATE bit is set.
>
> > So __speculation_ctrl_update() might see the new bits, but not
> > TIF_SPEC_UPDATE.
>
> Hm, right, scratch that. We'd need to do
On Tue, 27 Nov 2018, Thomas Gleixner wrote:
> That's racy and does not prevent the situation because the TIF flags are
> updated befor the UPDATE bit is set.
> So __speculation_ctrl_update() might see the new bits, but not
> TIF_SPEC_UPDATE.
Hm, right, scratch that. We'd need to do that
On Tue, 27 Nov 2018, Thomas Gleixner wrote:
> That's racy and does not prevent the situation because the TIF flags are
> updated befor the UPDATE bit is set.
> So __speculation_ctrl_update() might see the new bits, but not
> TIF_SPEC_UPDATE.
Hm, right, scratch that. We'd need to do that
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> On Mon, 26 Nov 2018, Thomas Gleixner wrote:
>
> How about the minimalistic aproach below? (only compile tested so far,
> applies on top of your latest WIP.x86/pti branch). The downside of course
> is wasting another TIF bit.
We need to waste another
On Tue, 27 Nov 2018, Jiri Kosina wrote:
> On Mon, 26 Nov 2018, Thomas Gleixner wrote:
>
> How about the minimalistic aproach below? (only compile tested so far,
> applies on top of your latest WIP.x86/pti branch). The downside of course
> is wasting another TIF bit.
We need to waste another
On Mon, 26 Nov 2018, Thomas Gleixner wrote:
> > 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
On Mon, 26 Nov 2018, Thomas Gleixner wrote:
> > 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
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
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
On 11/22/2018 11:37 PM, Ingo Molnar wrote:
>>> 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()
>>
On 11/22/2018 11:37 PM, Ingo Molnar wrote:
>>> 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()
>>
* Thomas Gleixner wrote:
> On Thu, 22 Nov 2018, Ingo Molnar wrote:
> > * Thomas Gleixner wrote:
> >
> > Had to read this twice, because the comment and the code are both correct
> > but deal with the inverse case. This might have helped:
> >
> > /*
> > * Immediately update the
* Thomas Gleixner wrote:
> On Thu, 22 Nov 2018, Ingo Molnar wrote:
> > * Thomas Gleixner wrote:
> >
> > Had to read this twice, because the comment and the code are both correct
> > but deal with the inverse case. This might have helped:
> >
> > /*
> > * Immediately update the
* Thomas Gleixner wrote:
> 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)
> > >
* Thomas Gleixner wrote:
> 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)
> > >
On Thu, 22 Nov 2018, Ingo Molnar wrote:
> * Thomas Gleixner wrote:
>
> Had to read this twice, because the comment and the code are both correct
> but deal with the inverse case. This might have helped:
>
> /*
>* Immediately update the speculation MSRs on the current task,
>
On Thu, 22 Nov 2018, Ingo Molnar wrote:
> * Thomas Gleixner wrote:
>
> Had to read this twice, because the comment and the code are both correct
> but deal with the inverse case. This might have helped:
>
> /*
>* Immediately update the speculation MSRs on the current task,
>
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 =
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 =
* Thomas Gleixner wrote:
> The update of the TIF_SSBD flag and the conditional speculation control MSR
> update is done in the ssb_prctl_set() function directly. The upcoming prctl
> support for controlling indirect branch speculation via STIBP needs the
> same mechanism.
>
> Split the code
* Thomas Gleixner wrote:
> The update of the TIF_SSBD flag and the conditional speculation control MSR
> update is done in the ssb_prctl_set() function directly. The upcoming prctl
> support for controlling indirect branch speculation via STIBP needs the
> same mechanism.
>
> Split the code
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
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
The update of the TIF_SSBD flag and the conditional speculation control MSR
update is done in the ssb_prctl_set() function directly. The upcoming prctl
support for controlling indirect branch speculation via STIBP needs the
same mechanism.
Split the code out and make it reusable.
Signed-off-by:
The update of the TIF_SSBD flag and the conditional speculation control MSR
update is done in the ssb_prctl_set() function directly. The upcoming prctl
support for controlling indirect branch speculation via STIBP needs the
same mechanism.
Split the code out and make it reusable.
Signed-off-by:
42 matches
Mail list logo
