On Sat, 2018-01-27 at 08:59 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 08, 2018 at 05:14:37PM +0100, Peter Zijlstra wrote:
> >
> > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> > >
> > > >
> > > > a good suggestion, but we encountered some issues with it either
> > > >
On Mon, Jan 08, 2018 at 05:14:37PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> > > a good suggestion, but we encountered some issues with it either
> > > crashing the kernel at boot or not properly turning on/off.
>
> The below boots, but I lack
On 01/09/2018 10:13 AM, David Woodhouse wrote:
> On Tue, 2018-01-09 at 09:55 -0800, Tim Chen wrote:
>>
>> Thomas,
>>
>> I'll be sending an updated patchset with boot option opt in for ibrs
>> and leave the control varaible out. I agree that we can worry about the
>> control variable later.
>
> Pl
On Tue, 2018-01-09 at 09:55 -0800, Tim Chen wrote:
>
> Thomas,
>
> I'll be sending an updated patchset with boot option opt in for ibrs
> and leave the control varaible out. I agree that we can worry about the
> control variable later.
Please base this on the spectre_v2= option that's already i
On 01/08/2018 04:29 PM, Borislav Petkov wrote:
> On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
>> From: Tim Chen
>> From: Andrea Arcangeli
>
> There's Co-Developed-by for this:
>
> - Co-Developed-by: states that the patch was also created by another
> developer
>along with the
On 01/09/2018 02:40 AM, Thomas Gleixner wrote:
> On Mon, 8 Jan 2018, Peter Zijlstra wrote:
>> On Mon, Jan 08, 2018 at 09:28:12AM -0800, Tim Chen wrote:
>>> On 01/08/2018 08:14 AM, Peter Zijlstra wrote:
On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
>> a good suggestion, bu
On Mon, 8 Jan 2018, Peter Zijlstra wrote:
> On Mon, Jan 08, 2018 at 09:28:12AM -0800, Tim Chen wrote:
> > On 01/08/2018 08:14 AM, Peter Zijlstra wrote:
> > > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> > >>> a good suggestion, but we encountered some issues with it either
> >
On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> From: Tim Chen
> From: Andrea Arcangeli
There's Co-Developed-by for this:
- Co-Developed-by: states that the patch was also created by another developer
along with the original author. This is useful at times when multiple
peop
>
> On Mon, 2018-01-08 at 18:42 +0100, Peter Zijlstra wrote:
> > On Mon, Jan 08, 2018 at 09:28:12AM -0800, Tim Chen wrote:
> > > On 01/08/2018 08:14 AM, Peter Zijlstra wrote:
> > > > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> > > >>> a good suggestion, but we encountered som
On Mon, 2018-01-08 at 18:42 +0100, Peter Zijlstra wrote:
> On Mon, Jan 08, 2018 at 09:28:12AM -0800, Tim Chen wrote:
> > On 01/08/2018 08:14 AM, Peter Zijlstra wrote:
> > > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> > >>> a good suggestion, but we encountered some issues with
On Mon, Jan 08, 2018 at 08:43:40PM +0300, Alexey Dobriyan wrote:
> > + len = sprintf(buf, "%d\n", READ_ONCE(*field));
>
> READ_ONCE isn't necessary as there is only one read being made.
Others might disagree but you shouldn't ever let gcc touch any memory
that can change under gcc without READ_
> + len = sprintf(buf, "%d\n", READ_ONCE(*field));
READ_ONCE isn't necessary as there is only one read being made.
> + len = min(count, sizeof(buf) - 1);
> + if (copy_from_user(buf, user_buf, len))
> + return -EFAULT;
> +
> + buf[len] = '\0';
> + if (kstrtouint(buf
On Mon, Jan 08, 2018 at 09:28:12AM -0800, Tim Chen wrote:
> On 01/08/2018 08:14 AM, Peter Zijlstra wrote:
> > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> >>> a good suggestion, but we encountered some issues with it either
> >>> crashing the kernel at boot or not properly turn
On 01/08/2018 08:14 AM, Peter Zijlstra wrote:
> On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
>>> a good suggestion, but we encountered some issues with it either
>>> crashing the kernel at boot or not properly turning on/off.
>
> The below boots, but I lack stuff to test the ena
On 01/08/2018 07:29 AM, Van De Ven, Arjan wrote:
>>> + if ((!c->cpu_index) && (boot_cpu_has(X86_FEATURE_SPEC_CTRL))) {
>>
>> We should test X86_BUG_SPECTRE_V1 here too before default enabling this,
>> no?
>
>
> we shouldn't default enable this.
>
Patch 7 disables ibrs if retpoline is in use.
On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> > a good suggestion, but we encountered some issues with it either
> > crashing the kernel at boot or not properly turning on/off.
The below boots, but I lack stuff to test the enabling.
--- a/arch/x86/include/asm/spec_ctrl.h
+++ b
On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> +static ssize_t ibrs_enabled_write(struct file *file,
> + const char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + char buf[32];
> + ssize_t len;
> + unsi
> > + if ((!c->cpu_index) && (boot_cpu_has(X86_FEATURE_SPEC_CTRL))) {
>
> We should test X86_BUG_SPECTRE_V1 here too before default enabling this,
> no?
we shouldn't default enable this.
On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> +static void spec_ctrl_flush_all_cpus(u32 msr_nr, u64 val)
> +{
> + int cpu;
> +
> + get_online_cpus();
> + for_each_online_cpu(cpu)
> + wrmsrl_on_cpu(cpu, msr_nr, val);
> + put_online_cpus();
> +}
> +
> +static
On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> +bool ibrs_inuse(void);
> +bool ibrs_inuse(void)
> +{
> + return ibrs_enabled == IBRS_ENABLED;
> +}
> +EXPORT_SYMBOL_GPL(ibrs_inuse);
Doesn't appear to actually be used anywhere...
On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> +void scan_spec_ctrl_feature(struct cpuinfo_x86 *c)
> +{
> + if ((!c->cpu_index) && (boot_cpu_has(X86_FEATURE_SPEC_CTRL))) {
We should test X86_BUG_SPECTRE_V1 here too before default enabling this,
no?
> + if (!ibrs_admin
On Fri, Jan 05, 2018 at 07:12:12PM -0800, Dave Hansen wrote:
> On 01/05/2018 06:12 PM, Tim Chen wrote:
> > .macro ENABLE_IBRS
> > - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> > + testl $1, dynamic_ibrs
> > + jz .Lskip_\@
>
> There was an earlier suggestion to use STATIC
On Sat, Jan 06, 2018 at 04:25:19PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Jan 06, 2018 at 10:10:59AM -0800, Tim Chen wrote:
> >
> >
> > On 01/06/2018 12:54 AM, Greg KH wrote:
> > > On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> > >> From: Tim Chen
> > >> From: Andrea Arcangel
On Sat, Jan 06, 2018 at 10:39:27PM +0100, Thomas Gleixner wrote:
> On Sat, 6 Jan 2018, Konrad Rzeszutek Wilk wrote:
> > On Sat, Jan 06, 2018 at 08:47:19PM +0100, Thomas Gleixner wrote:
> > > On Sat, 6 Jan 2018, Dave Hansen wrote:
> > >
> > > > On 01/06/2018 09:41 AM, Van De Ven, Arjan wrote:
> > >
> > it's a mistake though... retpoline is what people should be using
> > ... and only in super exception cases should IBRS even be considered
>
> Like on certain Skylake and Broadwell where using the retpoline won't suffice?
skylake is a bit more complex but that was discussed in earlier e
On Sat, Jan 06, 2018 at 09:34:01PM +, Van De Ven, Arjan wrote:
> > I agree. But this is what customers are told to inspect to see if they
> > are impacted. And if in the future versions this goes away or such - they
> > will freak out and cause needless escalations.
>
>
> it's a mistake thoug
On Sat, 6 Jan 2018, Konrad Rzeszutek Wilk wrote:
> On Sat, Jan 06, 2018 at 08:47:19PM +0100, Thomas Gleixner wrote:
> > On Sat, 6 Jan 2018, Dave Hansen wrote:
> >
> > > On 01/06/2018 09:41 AM, Van De Ven, Arjan wrote:
> > > .macro DISABLE_IBRS
> > > -ALTERNATIVE "jmp .Lskip_\@", "",
> I agree. But this is what customers are told to inspect to see if they
> are impacted. And if in the future versions this goes away or such - they
> will freak out and cause needless escalations.
it's a mistake though... retpoline is what people should be using
... and only in super except
On Sat, Jan 06, 2018 at 08:47:19PM +0100, Thomas Gleixner wrote:
> On Sat, 6 Jan 2018, Dave Hansen wrote:
>
> > On 01/06/2018 09:41 AM, Van De Ven, Arjan wrote:
> > .macro DISABLE_IBRS
> > - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> > + testl $1, dynamic_
On Sat, Jan 06, 2018 at 10:10:59AM -0800, Tim Chen wrote:
>
>
> On 01/06/2018 12:54 AM, Greg KH wrote:
> > On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> >> From: Tim Chen
> >> From: Andrea Arcangeli
> >>
> >> There are 2 ways to control IBRS
> >>
> >> 1. At boot time
> >> noib
On Sat, 6 Jan 2018, Dave Hansen wrote:
> On 01/06/2018 09:41 AM, Van De Ven, Arjan wrote:
> .macro DISABLE_IBRS
> -ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> +testl $1, dynamic_ibrs
> >>> On every system call we end up hammering on this 'dynamic_ibrs
On 01/06/2018 09:41 AM, Van De Ven, Arjan wrote:
.macro DISABLE_IBRS
- ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
+ testl $1, dynamic_ibrs
>>> On every system call we end up hammering on this 'dynamic_ibrs'
>>> variable. And it looks like it can be flipped via the IP
On 01/06/2018 09:33 AM, Dave Hansen wrote:
> On 01/06/2018 06:41 AM, Konrad Rzeszutek Wilk wrote:
>>> .macro DISABLE_IBRS
>>> - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
>>> + testl $1, dynamic_ibrs
>> On every system call we end up hammering on this 'dynamic_ibrs'
>> variable
On 01/06/2018 06:41 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
>> From: Tim Chen
>> From: Andrea Arcangeli
>>
>
>>
>> .macro DISABLE_IBRS
>> -ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
>> +testl $1, dynamic_ibrs
>
> On
On 01/06/2018 12:54 AM, Greg KH wrote:
> On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
>> From: Tim Chen
>> From: Andrea Arcangeli
>>
>> There are 2 ways to control IBRS
>>
>> 1. At boot time
>> noibrs kernel boot parameter will disable IBRS usage
>>
>> Otherwise if the above pa
> >> .macro DISABLE_IBRS
> >> - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> >> + testl $1, dynamic_ibrs
> > On every system call we end up hammering on this 'dynamic_ibrs'
> > variable. And it looks like it can be flipped via the IPI mechanism.
> >
> > Would it make sense for this
On 01/06/2018 06:41 AM, Konrad Rzeszutek Wilk wrote:
>> .macro DISABLE_IBRS
>> -ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
>> +testl $1, dynamic_ibrs
> On every system call we end up hammering on this 'dynamic_ibrs'
> variable. And it looks like it can be flipped via the IPI
On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> From: Tim Chen
> From: Andrea Arcangeli
>
> There are 2 ways to control IBRS
>
> 1. At boot time
> noibrs kernel boot parameter will disable IBRS usage
>
> Otherwise if the above parameters are not specified, the system
> will ena
On Fri, Jan 05, 2018 at 06:12:19PM -0800, Tim Chen wrote:
> From: Tim Chen
> From: Andrea Arcangeli
>
> There are 2 ways to control IBRS
>
> 1. At boot time
> noibrs kernel boot parameter will disable IBRS usage
>
> Otherwise if the above parameters are not specified, the system
> will ena
On 01/05/2018 06:12 PM, Tim Chen wrote:
> .macro ENABLE_IBRS
> - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> + testl $1, dynamic_ibrs
> + jz .Lskip_\@
There was an earlier suggestion to use STATIC_JUMP_IF_... here. That's
a good suggestion, but we encountered some
From: Tim Chen
From: Andrea Arcangeli
There are 2 ways to control IBRS
1. At boot time
noibrs kernel boot parameter will disable IBRS usage
Otherwise if the above parameters are not specified, the system
will enable ibrs and ibpb usage if the cpu supports it.
2. At run time
echo 0 > /
41 matches
Mail list logo
