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
33 matches
Mail list logo
