Re: [PATCH 0/7] IBRS patch series
From: David Woodhouse
Date: Fri Jan 05 2018 - 11:38:02 EST
On Fri, 2018-01-05 at 17:05 +0100, Andrea Arcangeli wrote:
> On Fri, Jan 05, 2018 at 03:38:24PM +0000, 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.
> >
> > When looking at optimisations, it is rare for us to say "oh, well it
> > opens up only a *small* theoretical security hole, but it's faster so
> > that's OK".
> I couldn't express any better than the above, the way I look at
> repotlines.
>
> Now seeing how this thing escalates with 2-way gcc code emission with
> amd version that will not have ibrs at all to call it around the bios
> etc... and IBRS skylake is still needed as a 3-way alternative and no
> code exists to even patch it all at boot like that, and then qemu has
> to be compiled with reptoline and 2-way alternative there too, to
> achieve ibrs 2 ibpb 1, it's not looking like the way to go to me.
>
> Not in the short term at least, and for the long term "reptoline" is
> guaranteed a totally useless effort.
>
> reptoline is like highmem kmap() etc... eventually nobody will ever
> use reptoline. reptoline is more interesting for downstream in fact if
> something where at least we won't have to deal with that forever where
> there's more control on the toolchain used, and after a certain number
> of years that code expires.
>
> I can imagine we'll unfortunately have to deal with reptoline at some
> point, but starting with reptoline at least looks backwards,
> especially if it's the long term you're planning for.
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 working fine; it isn't *that*
complex.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature