Re: [PATCH 0/7] IBRS patch series

[Andrea Arcangeli <aarcange@redhat.com>]

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.

Thanks,
Andrea