On Wed, Jan 10, 2018 at 01:35:45PM -0800, Tim Chen wrote:
> time may not provide full protection on all cpu models.
All right no problem at all, it's fixed up.
Until very recently the majority of microcodes wasn't available in the
first place so I guess it's no big issue if in a subset of those t
On 01/10/2018 05:53 AM, Van De Ven, Arjan wrote:
>> ibrs_enabled 2:
>>
>> sets IBRS always in host
>
> this is not secure
>
>> This matches the semantics described here by Tim patchset on lkml:
>>
>> https://marc.info/?l=linux-kernel&m=151520606320646
>
> I will talk to Tim, it's not right.
>
>
On Wed, 2018-01-10 at 16:47 +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 03:24:17PM +, David Woodhouse wrote:
> > Since it achieves nothing¹ but to make userspace run slower, there's no
> > need to write it again on returning to userspace. It will perform that
> > function just fine
On Wed, Jan 10, 2018 at 03:24:17PM +, David Woodhouse wrote:
> Since it achieves nothing¹ but to make userspace run slower, there's no
> need to write it again on returning to userspace. It will perform that
> function just fine without doing so.
Ok, very glad we are on the same page now.
Not
On Wed, 2018-01-10 at 16:13 +0100, Andrea Arcangeli wrote:
>
> Can you also tell if IBRS must be written as a barrier to SPEC_CTRL in
> return to userland (kernel exit) when ibrs_enabled 2? Generally we
> wouldn't run a barrier there with ibrs_enabled 2, but absolutely
> nothing is intuitive here
On Wed, Jan 10, 2018 at 06:59:54AM -0800, Dave Hansen wrote:
> On 01/10/2018 06:10 AM, Andrea Arcangeli wrote:
> > Tim and Dave please comment too, Tim you originally wrote that code
> > that leaves IBRS always on and never toggles it in the kernel entry
> > point so you must know full well if Arja
On 01/10/2018 06:10 AM, Andrea Arcangeli wrote:
> Tim and Dave please comment too, Tim you originally wrote that code
> that leaves IBRS always on and never toggles it in the kernel entry
> point so you must know full well if Arjan is correct that you must
> toggle IBRS every time you enter kernel
> Hello,
>
> On Wed, Jan 10, 2018 at 02:46:22PM +0100, Thomas Gleixner wrote:
> > So here is the simple list of questions all to be answered with YES or
> > NO. I don't want to see any of the 'but, though ...'. We all know by now
> > that it's CPU dependent and slow and whatever and that IBRS_ATT
Hello,
On Wed, Jan 10, 2018 at 02:46:22PM +0100, Thomas Gleixner wrote:
> So here is the simple list of questions all to be answered with YES or
> NO. I don't want to see any of the 'but, though ...'. We all know by now
> that it's CPU dependent and slow and whatever and that IBRS_ATT will be in
>
On Wed, 2018-01-10 at 14:46 +0100, Thomas Gleixner wrote:
>
> So here is the simple list of questions all to be answered with YES or
> NO. I don't want to see any of the 'but, though ...'. We all know by now
> that it's CPU dependent and slow and whatever and that IBRS_ATT will be in
> future CPUs
> ibrs_enabled 2:
>
> sets IBRS always in host
this is not secure
> This matches the semantics described here by Tim patchset on lkml:
>
> https://marc.info/?l=linux-kernel&m=151520606320646
I will talk to Tim, it's not right.
> I can tell in practice it works as I described in all microco
On Wed, 10 Jan 2018, Van De Ven, Arjan wrote:
> > So here is the simple list of questions all to be answered with YES or
> > NO. I don't want to see any of the 'but, though ...'. We all know by now
> > that it's CPU dependent and slow and whatever and that IBRS_ATT will be in
> > future CPUs. So ge
On Wed, Jan 10, 2018 at 01:45:52PM +, Van De Ven, Arjan wrote:
>
> > Andrea, what you're saying is directly contradicting what I've heard
> > from Intel.
> >
> > The documentation already distinguishes between IBRS on current
> > hardware, and IBRS_ATT on future hardware. If it was the case
> So here is the simple list of questions all to be answered with YES or
> NO. I don't want to see any of the 'but, though ...'. We all know by now
> that it's CPU dependent and slow and whatever and that IBRS_ATT will be in
> future CPUs. So get your act together and tell a clear YES or NO.
I wil
On Wed, 10 Jan 2018, David Woodhouse wrote:
> Andrea, what you're saying is directly contradicting what I've heard
> from Intel.
>
> The documentation already distinguishes between IBRS on current
> hardware, and IBRS_ATT on future hardware. If it was the case that IBRS
> on current hardware is a
> Andrea, what you're saying is directly contradicting what I've heard
> from Intel.
>
> The documentation already distinguishes between IBRS on current
> hardware, and IBRS_ATT on future hardware. If it was the case that IBRS
> on current hardware is a set-and-forget option and completely disab
> On Wed, Jan 10, 2018 at 12:12:53PM +, David Woodhouse wrote:
> > IBRS is like a barrier. You must write it between the 'problematic'
> > loading of the branch targets, and the kernel code which might be
> > affected.
> >
> > You cannot, on current hardware, merely set it once and forget abo
On Wed, Jan 10, 2018 at 02:10:10PM +0100, Andrea Arcangeli wrote:
> It's still incredibly faster to shutdown part of the CPU temporarily
> than to flush its internal state as a whole with IBPB. If it wouldn't
> be the case ibrs_enabled 0 ibpb_enabled 2 special mode would perform
> better (but that'
On Wed, 10 Jan 2018, Andrea Arcangeli wrote:
> Which in current silicon IBP speculation is turned off always,
So this is clearly the source of confusion.
If that's the case, what you are saying makes sense. Where is this
information coming from? It definitely is not in the Intel documentation
On Wed, Jan 10, 2018 at 02:05:51PM +0100, Andrea Arcangeli wrote:
> Also note, the slowdown of setting IBRS varies with older CPUs being
To give a further detail, older CPUs to provide IBRS semantics have to
do something even less finegrined that doesn't just restricts
speculation across IBRS less
On Wed, 2018-01-10 at 13:57 +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 01:47:22PM +0100, Jiri Kosina wrote:
> >
> > On Wed, 10 Jan 2018, Andrea Arcangeli wrote:
> >
> > >
> > > Perhaps the confusing come from "less privileged prediction mode" and
> > > you thought that meant "less
On Wed, Jan 10, 2018 at 02:02:02PM +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 12:51:13PM +, David Woodhouse wrote:
> > If it worked as Andrea suggests, then there would be absolutely no
> > point in the patches we've seen which add the IBRS-frobbing on syscall
> > entry and vmexit
On Wed, Jan 10, 2018 at 12:51:13PM +, David Woodhouse wrote:
> If it worked as Andrea suggests, then there would be absolutely no
> point in the patches we've seen which add the IBRS-frobbing on syscall
> entry and vmexit.
This is perhaps what you're missing I think, there is a huge point:
per
On Wed, Jan 10, 2018 at 01:47:22PM +0100, Jiri Kosina wrote:
> On Wed, 10 Jan 2018, Andrea Arcangeli wrote:
>
> > Perhaps the confusing come from "less privileged prediction mode" and
> > you thought that meant "less privileged ring mode". It says "predction
> > mode" not ring 3.
>
> Well, predic
On Wed, 2018-01-10 at 13:47 +0100, Jiri Kosina wrote:
> On Wed, 10 Jan 2018, Andrea Arcangeli wrote:
>
> > Perhaps the confusing come from "less privileged prediction mode" and
> > you thought that meant "less privileged ring mode". It says "predction
> > mode" not ring 3.
>
> Well, prediction mo
On Wed, 10 Jan 2018, Andrea Arcangeli wrote:
> Perhaps the confusing come from "less privileged prediction mode" and
> you thought that meant "less privileged ring mode". It says "predction
> mode" not ring 3.
Well, prediction mode is defined by "CPL3 vs CPL0-2" and "VMX root vs VMX
non-root", w
On Wed, Jan 10, 2018 at 12:29:44PM +, David Woodhouse wrote:
> On Wed, 2018-01-10 at 13:17 +0100, Andrea Arcangeli wrote:
> > On Wed, Jan 10, 2018 at 12:09:34PM +, David Woodhouse wrote:
> > > That is not consistent with the documentation I've seen, which Intel
> > > have so far utterly fai
On Wed, 2018-01-10 at 13:17 +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 12:09:34PM +, David Woodhouse wrote:
> > That is not consistent with the documentation I've seen, which Intel
> > have so far utterly failed to publish AFAICT.
> >
> > "a near indirect jump/call/return may be
On Wed, Jan 10, 2018 at 01:20:45PM +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 12:12:53PM +, David Woodhouse wrote:
> > IBRS is like a barrier. You must write it between the 'problematic'
> > loading of the branch targets, and the kernel code which might be
> > affected.
> >
> > Y
On Wed, Jan 10, 2018 at 12:12:53PM +, David Woodhouse wrote:
> IBRS is like a barrier. You must write it between the 'problematic'
> loading of the branch targets, and the kernel code which might be
> affected.
>
> You cannot, on current hardware, merely set it once and forget about
> it. That
On Wed, Jan 10, 2018 at 12:09:34PM +, David Woodhouse wrote:
> That is not consistent with the documentation I've seen, which Intel
> have so far utterly failed to publish AFAICT.
>
> "a near indirect jump/call/return may be affected by code in a less privileged
> prediction mode that executed
On Wed, 2018-01-10 at 13:07 +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 01:01:58PM +0100, Andrea Arcangeli wrote:
> > On Wed, Jan 10, 2018 at 11:58:54AM +, David Woodhouse wrote:
> > > On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote:
> > > > On Wed, Jan 10, 2018 at 09:27:
On Wed, 2018-01-10 at 13:01 +0100, Andrea Arcangeli wrote:
>
> > On all current hardware, if you only set IBRS when you exit a guest,
> > then you are not protecting yourself from userspace at all. IBRS acts
> > as a *barrier* in all current hardware.
>
> Kernel memory is 100% protected if you se
On Wed, Jan 10, 2018 at 01:01:58PM +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 11:58:54AM +, David Woodhouse wrote:
> > On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote:
> > > On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote:
> > > > I don't know why you're
On Wed, Jan 10, 2018 at 11:58:54AM +, David Woodhouse wrote:
> On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote:
> > On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote:
> > > I don't know why you're calling that 'IBRS=2'; are you getting
> > confused
> > > by Andrea's dist
On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote:
> > I don't know why you're calling that 'IBRS=2'; are you getting
> confused
> > by Andrea's distro horridness?
>
> Eh, yes he's got confused. ibrs_enabled 2 simply means
On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote:
> I don't know why you're calling that 'IBRS=2'; are you getting confused
> by Andrea's distro horridness?
Eh, yes he's got confused. ibrs_enabled 2 simply means to leave IBRS
set in SPEC_CTLR 100% of the time, except in guest mode.
On Wed, Jan 10, 2018 at 11:22:53AM +, David Woodhouse wrote:
> On Wed, 2018-01-10 at 11:03 +0100, Peter Zijlstra wrote:
> > On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote:
> > >
> > > >
> > > > The only question I have is if retpoline works at all on SKL (with ucode
> > > > u
On Wed, 10 Jan 2018, David Woodhouse wrote:
> On Wed, 2018-01-10 at 11:03 +0100, Peter Zijlstra wrote:
> > On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote:
> > >
> > > >
> > > > The only question I have is if retpoline works at all on SKL (with ucode
> > > > update); BDW needs the
On Wed, 2018-01-10 at 11:03 +0100, Peter Zijlstra wrote:
> On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote:
> >
> > >
> > > The only question I have is if retpoline works at all on SKL (with ucode
> > > update); BDW needs the ucode update for retpoline to work because of the
> > >
On Wed, Jan 10, 2018 at 09:27:59AM +, David Woodhouse wrote:
> > The only question I have is if retpoline works at all on SKL (with ucode
> > update); BDW needs the ucode update for retpoline to work because of the
> > RSB fallback.
>
> As I understand it, Skylake is never getting the IBRS_ATT
On Wed, 2018-01-10 at 10:22 +0100, Peter Zijlstra wrote:
> On Tue, Jan 09, 2018 at 06:02:53PM -0800, Dave Hansen wrote:
> >
> > On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> > >
> > > --- a/arch/x86/kernel/cpu/bugs.c
> > > +++ b/arch/x86/kernel/cpu/bugs.c
> > > @@ -79,6 +79,7 @@ enum spectre_v
On Tue, Jan 09, 2018 at 06:02:53PM -0800, Dave Hansen wrote:
> On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -79,6 +79,7 @@ enum spectre_v2_mitigation_cmd {
> > SPECTRE_V2_CMD_RETPOLINE,
> > SPECTRE_V2_CMD_RET
On Tue, Jan 9, 2018 at 8:02 PM, Dave Hansen wrote:
> On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
>> --- a/arch/x86/kernel/cpu/bugs.c
>> +++ b/arch/x86/kernel/cpu/bugs.c
>> @@ -79,6 +79,7 @@ enum spectre_v2_mitigation_cmd {
>> SPECTRE_V2_CMD_RETPOLINE,
>> SPECTRE_V2_CMD_RETPOLINE_GEN
On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -79,6 +79,7 @@ enum spectre_v2_mitigation_cmd {
> SPECTRE_V2_CMD_RETPOLINE,
> SPECTRE_V2_CMD_RETPOLINE_GENERIC,
> SPECTRE_V2_CMD_RETPOLINE_AMD,
> + SPECTRE
Add the minimal infrastructure to control the speculation control feature.
- Integrate it into the spectre_v2 coammand line parser and the mitigation
selector function. The conditional selector function is a placeholder
right now, which needs to be expanded with CPU specific decision
fun
46 matches
Mail list logo
