On Fri, 2018-01-05 at 17:42 +0100, Andrea Arcangeli wrote:
> On Fri, Jan 05, 2018 at 04:37:30PM +, David Woodhouse wrote:
> > You are completely ignoring pre-Skylake here.
> >
> > On pre-Skylake, retpoline is perfectly sufficient and it's a *lot*
> > faster than the IBRS option which is almost
> On Fri, Jan 05, 2018 at 04:37:30PM +, David Woodhouse wrote:
> > You are completely ignoring pre-Skylake here.
> >
> > On pre-Skylake, retpoline is perfectly sufficient and it's a *lot*
> > faster than the IBRS option which is almost prohibitively slow.
> >
> > We didn't do it just for fun. A
On Fri, Jan 05, 2018 at 04:37:30PM +, David Woodhouse wrote:
> You are completely ignoring pre-Skylake here.
>
> On pre-Skylake, retpoline is perfectly sufficient and it's a *lot*
> faster than the IBRS option which is almost prohibitively slow.
>
> We didn't do it just for fun. And it's work
On Fri, 2018-01-05 at 17:05 +0100, Andrea Arcangeli wrote:
> On Fri, Jan 05, 2018 at 03:38:24PM +, David Woodhouse wrote:
> >
> > We had IBRS first, and especially on Broadwell and earlier, its
> > performance really is painful.
> >
> > Then came retpoline, purely as an optimisation. A very *
On Fri, Jan 05, 2018 at 03:38:24PM +, David Woodhouse wrote:
> We had IBRS first, and especially on Broadwell and earlier, its
> performance really is painful.
>
> Then came retpoline, purely as an optimisation. A very *important*
> performance improvement, but an optimisation nonetheless.
>
>
On Fri, 2018-01-05 at 14:42 +, Van De Ven, Arjan wrote:
> This is why I said I would like to see retpoline be the default, with
> IBRS an opt-in for the paranoid. I guess David will turn that on ;-)
I can live with that.
It really depends how you look at it.
We had IBRS first, and especiall
On Fri, Jan 05, 2018 at 02:52:33PM +, Van De Ven, Arjan wrote:
> I'm sorry but your whole statement reeks a little bit of "perfect is the
> enemy of good"
My point is exactly that this sentences could apply to spectre
variant#2 in the first place..
If we start moving in any direction, either
On Fri, 5 Jan 2018, Andrea Arcangeli wrote:
> On Thu, Jan 04, 2018 at 09:22:34PM +, Van De Ven, Arjan wrote:
> > personally I am comfortable with retpoline on Skylake, but I would
> >like to have IBRS as an opt in for the paranoid.
>
> I think this whole variant#2 issue has to be fixed mathema
On Fri, 2018-01-05 at 15:26 +0100, Paolo Bonzini wrote:
> Those from November seem way too early to include IBRS/IBPB. Maybe the
> two from December 3rd, but I wouldn't be 100% sure.
So, for my CPU with updated microcode:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
mod
>
> Doing a huge amount of work with reptoline and then you find SMM is
> called reproducibly somehow and a new PoC could exist for it, not fun.
retpoline we want for broadwell and earlier anyway..
I'm sorry but your whole statement reeks a little bit of "perfect is the enemy
of good"
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, January 05, 2018 3:32 AM
> To: Van De Ven, Arjan ; Linus Torvalds
> ; David Woodhouse
> Cc: Tim Chen ; Thomas Gleixner
> ; Andy Lutomirski ; Greg KH
> ; Hansen, Dave
On Thu, Jan 04, 2018 at 09:22:34PM +, Van De Ven, Arjan wrote:
> personally I am comfortable with retpoline on Skylake, but I would
>like to have IBRS as an opt in for the paranoid.
I think this whole variant#2 issue has to be fixed mathematically or
not at all, the reason is that it's already
> > So long as the underlying binary satisfies the precondition that it
> > will not underflow its own RSB.
> >
> > Then we if we subsequently guarantee never to _reduce_ the number of
> > entries in its RSB at any point remote to its own execution, then the
> > precondition is preserved and underf
On Fri, 2018-01-05 at 03:52 -0800, Paul Turner wrote:
>
> These are also mitigatable; the retpoline sequence itself will never
> result in an RSB underflow.
Unless an event occurs which clears the RSB between the CALL and the
RET of the retpoline.
> So long as the underlying binary satisfies the
On 05/01/2018 15:01, Greg KH wrote:
>> Obviously it lacks a *lot* of processors (especially pre-Haswell).
>
> I'm running Arch, but it would be nice to know where those microcode
> updates came from, given that they aren't on the "official" Intel page
> yet :)
Those from November seem way too ear
On Fri, Jan 05, 2018 at 02:47:45PM +0100, Yves-Alexis Perez wrote:
> On Fri, 2018-01-05 at 14:28 +0100, Greg KH wrote:
> > > iucode-tool -L -tr n10ur16w.iso |grep 2017-11
> > >001/020: sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size
> > > 18432
> >
> > That's been out for a while no
On Fri, 2018-01-05 at 14:28 +0100, Greg KH wrote:
> > iucode-tool -L -tr n10ur16w.iso |grep 2017-11
> >001/020: sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size
> > 18432
>
> That's been out for a while now:
> https://downloadcenter.intel.com/download/27337/Linux-Processor-Mi
On Thu, Jan 04, 2018 at 10:01:52PM +0100, Yves-Alexis Perez wrote:
> On Thu, 2018-01-04 at 11:10 -0800, Tim Chen wrote:
> > > Are there plans to make the corresponding microcode support available?
> > >
> >
> > The microcode patches should be released soon.
>
> In the meantime, Lenovo has starte
On Fri, Jan 5, 2018 at 3:32 AM, Paolo Bonzini wrote:
> On 04/01/2018 22:22, Van De Ven, Arjan wrote:
>> this is about a level of paranoia you are comfortable with.
>>
>> Retpoline on Skylake raises the bar for the issue enormously, but
>> there are a set of corner cases that exist and that are not
On Thu, Jan 4, 2018 at 11:33 AM, Linus Torvalds
wrote:
> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote:
>>
>> On Skylake the target for a 'ret' instruction may also come from the
>> BTB. So if you ever let the RSB (which remembers where the 'call's came
>> from get empty, you end up vuln
On 04/01/2018 22:22, Van De Ven, Arjan wrote:
> this is about a level of paranoia you are comfortable with.
>
> Retpoline on Skylake raises the bar for the issue enormously, but
> there are a set of corner cases that exist and that are not trivial
> to prove you dealt with them.
>
> personally I
On Fri, 2018-01-05 at 06:25 +0100, Florian Weimer wrote:
>
> Retpoline also looks incompatible with CET, so future Intel CPUs will
> eventually need a different approach anyway.
CPUs with CET will have the indirect branch problem fixed, so the
retpoline ALTERNATIVE will be used which is a bare 'j
* Linus Torvalds:
> On Thu, Jan 4, 2018 at 9:56 AM, Tim Chen wrote:
>>
>> Speculation on Skylake and later requires these patches ("dynamic IBRS")
>> be used instead of retpoline[1].
>
> Can somebody explain this part?
>
> I was assuming that retpoline would work around this issue on all uarchs.
> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse
> wrote:
> >
> > On Skylake the target for a 'ret' instruction may also come from the
> > BTB. So if you ever let the RSB (which remembers where the 'call's came
> > from get empty, you end up vulnerable.
>
> That sounds like it could cause mispr
On Thu, 2018-01-04 at 11:10 -0800, Tim Chen wrote:
> > Are there plans to make the corresponding microcode support available?
> >
>
> The microcode patches should be released soon.
In the meantime, Lenovo has started issuing BIOS/UEFI updates which include
microcode updates for this.
See for ex
On Thu, 2018-01-04 at 19:40 +, Andrew Cooper wrote:
>
> Also remember that sibling threads share a BTB, so you can't rely on
> isolated straight-line codepath on the current cpu for safety. (e.g. by
> issuing an IBPB on every entry to supervisor mode).
That is just one of a whole litany of re
On 04/01/18 19:33, Linus Torvalds wrote:
> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote:
>> On Skylake the target for a 'ret' instruction may also come from the
>> BTB. So if you ever let the RSB (which remembers where the 'call's came
>> from get empty, you end up vulnerable.
> That sou
On Thu, 2018-01-04 at 11:33 -0800, Linus Torvalds wrote:
> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote:
> >
> > On Skylake the target for a 'ret' instruction may also come from the
> > BTB. So if you ever let the RSB (which remembers where the 'call's came
> > from get empty, you end up
On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse wrote:
>
> On Skylake the target for a 'ret' instruction may also come from the
> BTB. So if you ever let the RSB (which remembers where the 'call's came
> from get empty, you end up vulnerable.
That sounds like it could cause mispredicts, but it d
On Thu, 2018-01-04 at 11:00 -0800, Linus Torvalds wrote:
> On Thu, Jan 4, 2018 at 9:56 AM, Tim Chen
> wrote:
> >
> >
> > Speculation on Skylake and later requires these patches ("dynamic
> > IBRS")
> > be used instead of retpoline[1].
> Can somebody explain this part?
>
> I was assuming that re
On 01/04/2018 11:05 AM, Justin Forbes wrote:
> On Thu, Jan 4, 2018 at 11:56 AM, Tim Chen wrote:
>> This patch series enables the basic detection and usage of x86 indirect
>> branch speculation feature. It enables the indirect branch restricted
>> speculation (IBRS) on kernel entry and disables it
On Thu, Jan 4, 2018 at 11:56 AM, Tim Chen wrote:
> This patch series enables the basic detection and usage of x86 indirect
> branch speculation feature. It enables the indirect branch restricted
> speculation (IBRS) on kernel entry and disables it on exit.
> It enumerates the indirect branch pred
On Thu, Jan 4, 2018 at 9:56 AM, Tim Chen wrote:
>
> Speculation on Skylake and later requires these patches ("dynamic IBRS")
> be used instead of retpoline[1].
Can somebody explain this part?
I was assuming that retpoline would work around this issue on all uarchs.
This seems to say "retpoline
This patch series enables the basic detection and usage of x86 indirect
branch speculation feature. It enables the indirect branch restricted
speculation (IBRS) on kernel entry and disables it on exit.
It enumerates the indirect branch prediction barrier (IBPB).
The x86 IBRS feature requires corr
34 matches
Mail list logo
