Thomas,
>
> The goal is to glue the mitigation decision on dumpable. That's debatable,
> but understandable, so let's not go into that discussion.
>
> There are two ways to modify dumpable:
>
> 1) prctl(PR_SET_DUMPABLE)
>
> 2) operations which change UID/GID and end up in commit_creds()
>
Thomas,
>
> The goal is to glue the mitigation decision on dumpable. That's debatable,
> but understandable, so let's not go into that discussion.
>
> There are two ways to modify dumpable:
>
> 1) prctl(PR_SET_DUMPABLE)
>
> 2) operations which change UID/GID and end up in commit_creds()
>
On 11/07/2018 10:33 AM, Waiman Long wrote:
> On 11/06/2018 07:18 PM, Tim Chen wrote:
>> Thomas,
>>
> 2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
>in the slow work path.
There can be tasks that don't do any syscalls, and it seems like we can
have
On 11/07/2018 10:33 AM, Waiman Long wrote:
> On 11/06/2018 07:18 PM, Tim Chen wrote:
>> Thomas,
>>
> 2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
>in the slow work path.
There can be tasks that don't do any syscalls, and it seems like we can
have
Tim,
On Tue, 6 Nov 2018, Tim Chen wrote:
> >>> 2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
> >>>in the slow work path.
> >>
> >> There can be tasks that don't do any syscalls, and it seems like we can
> >> have MSRs getting out of sync?
> >
> > Setting the TIF
Tim,
On Tue, 6 Nov 2018, Tim Chen wrote:
> >>> 2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
> >>>in the slow work path.
> >>
> >> There can be tasks that don't do any syscalls, and it seems like we can
> >> have MSRs getting out of sync?
> >
> > Setting the TIF
On 11/06/2018 07:18 PM, Tim Chen wrote:
> Thomas,
>
2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
in the slow work path.
>>> There can be tasks that don't do any syscalls, and it seems like we can
>>> have MSRs getting out of sync?
>> Setting the TIF flag
On 11/06/2018 07:18 PM, Tim Chen wrote:
> Thomas,
>
2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
in the slow work path.
>>> There can be tasks that don't do any syscalls, and it seems like we can
>>> have MSRs getting out of sync?
>> Setting the TIF flag
Thomas,
>
>>> 2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
>>>in the slow work path.
>>
>> There can be tasks that don't do any syscalls, and it seems like we can
>> have MSRs getting out of sync?
>
> Setting the TIF flag directly in a remote task is wrong. It
Thomas,
>
>>> 2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
>>>in the slow work path.
>>
>> There can be tasks that don't do any syscalls, and it seems like we can
>> have MSRs getting out of sync?
>
> Setting the TIF flag directly in a remote task is wrong. It
Tim,
On Mon, 5 Nov 2018, Tim Chen wrote:
> > 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 not crazy about sending IPIs too.
Tim,
On Mon, 5 Nov 2018, Tim Chen wrote:
> > 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 not crazy about sending IPIs too.
Thomas,
>
>
> 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 not crazy about sending IPIs too. Hence the original implementation
Thomas,
>
>
> 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 not crazy about sending IPIs too. Hence the original implementation
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)
> +{
> +
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)
> +{
> +
Thomas,
>> +if (tifp & _TIF_UPDATE_SPEC_CTRL)
>> +clear_tsk_thread_flag(prev_p, TIF_UPDATE_SPEC_CTRL);
>> +
>> +if (tifn & _TIF_UPDATE_SPEC_CTRL) {
>> +clear_tsk_thread_flag(next_p, TIF_UPDATE_SPEC_CTRL);
>> +tifn &= ~_TIF_UPDATE_SPEC_CTRL;
>> +}
Thomas,
>> +if (tifp & _TIF_UPDATE_SPEC_CTRL)
>> +clear_tsk_thread_flag(prev_p, TIF_UPDATE_SPEC_CTRL);
>> +
>> +if (tifn & _TIF_UPDATE_SPEC_CTRL) {
>> +clear_tsk_thread_flag(next_p, TIF_UPDATE_SPEC_CTRL);
>> +tifn &= ~_TIF_UPDATE_SPEC_CTRL;
>> +}
Tim,
On Tue, 30 Oct 2018, Tim Chen wrote:
> void arch_set_security(struct task_struct *tsk, unsigned int value)
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 943e90d..048b7f4b 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -426,7
Tim,
On Tue, 30 Oct 2018, Tim Chen wrote:
> void arch_set_security(struct task_struct *tsk, unsigned int value)
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 943e90d..048b7f4b 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -426,7
The SPEC_CTRL MSR of a remote CPU cannot be updated immediately when
TIF_STIBP flag is changed on a task running on the remote CPU.
If next task's TIF_STIBP flag happened to be the same as the updated
TIF_STIBP on the previous task on the next context switch, the SPEC_CTRL
MSR update is missed as
The SPEC_CTRL MSR of a remote CPU cannot be updated immediately when
TIF_STIBP flag is changed on a task running on the remote CPU.
If next task's TIF_STIBP flag happened to be the same as the updated
TIF_STIBP on the previous task on the next context switch, the SPEC_CTRL
MSR update is missed as
22 matches
Mail list logo
