On Sat, 2018-01-13 at 13:01 +0100, Florian Weimer wrote: > * David Woodhouse: > > > > > > > > > Do you assume that you will eventually apply run-time patching to > > > thunks (in case they aren't needed)? > > "eventually"? We've been doing it for weeks. We are desperate to > > release the kernel.... when can we have agreement on at *least* the > > command line option and the name of the thunk? Internal implementation > > details we really don't care about, but those we do. > > Thanks. Are you content with patching just the thunk, or would you > prefer patching the control transfer to it, too?
As things stand, GCC will put the target into a register and then call
the thunk.
We currently patch the thunk to turn it into a straight 'jmp *%\reg'
instead of the full retpoline (or perhaps 'lfence; jmp *\reg' on AMD).
This means we have the direct unconditional branch instruction emitted
by GCC, directly followed by a branch-to-register. And presumably you
aren't talking about deep magic here, just turning that 'call
__x86_indirect_branch_\reg' back into a 'call *\reg' inline in the C
code? Probably not even eliminating the load into the register in the
first place, for targets which actually came from memory?
So right now, for this specific use case, we are content with just
patching the thunk. It's not like that unconditional direct branch to
the thunk is hard for the CPU to predict. ;)
Now, if we're talking about the general case of wanting to runtime-
patch code emitted by GCC, there are much better use cases. Like
letting you emit 'movbe;nop;nop;nop' in appropriate cases, but telling
us where they are so we can hotpatch them into a 'mov;bswap' on CPUs
that need it. And other similar cases which are *much* more interesting
than the retpoline thing.¹
If we get that generic capability, then by all means we might as well
do the retpoline thunks too in future. But we're not losing sleep over
it right now.
What we're losing sleep over right now is the fact that we haven't even
got an agreement that the command line options, and the thunk symbol
name, are OK to use. Regardless of how you *implement* those, we really
want to commit the kernel code to use it within the next 24 hours...
¹ I actually just had a *really* nasty thought about that. If I start
the C file with asm(".include movbe-hack.h") and movbe-hack.h contains
a '.macro movbe' which does the normal Linux ALTERNATIVE thing... no,
you're going to come and hurt me, aren't you...
smime.p7s
Description: S/MIME cryptographic signature
