Messages in this thread | | | Date | Tue, 19 Jul 2022 02:23:22 +0200 | From | Peter Zijlstra <> | Subject | Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation |
| |
On Mon, Jul 18, 2022 at 05:11:27PM -0700, Linus Torvalds wrote: > On Mon, Jul 18, 2022 at 5:03 PM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > So it already only adds the pattern to things that have their address > > taken, not all functions? > > > > If so, that's simple enough to sort out: don't do any RSB stack > > adjustment for those thunks AT ALL. > > > > Because they should just then end up with a jump to the "real" target, > > and that real target will do the RSB stack thing. > > Put another way, let's say that you have a function that looks like this: > > int silly(void) > { > return 0; > } > > and now you have two cases: > > - the "direct callable version" of that function looks exactly the > way it always has looked, and gets the 16 bytes of padding for it, and > the RSB counting can happen in that padding > > - the "somebody took the address of this function" creates code that > has the hash marker before it, and has the hash check, and then does a > "jmp silly" to actually jump to the real code. > > So what the RSB counting does is just ignore that second case entirely > as far as the RSB code generation goes. No need to have any padding > for it at all, it has that (completely different) kCFI padding > instead. > > Instead, only the "real" silly function gets that RSB code, and the > "jmp silly" from the kCFI thunk needs to be updated to point to the > RSB thunk in front of it. > > Yes, yes, it makes indirect calls slightly more expensive than direct > calls (because that kCFI thing can't just fall through to the real > thing), but considering all the *other* costs of indirect calls, the > cost of having that one "jmp" instruction doesn't really seem to > matter, does it?
So it's like 2:15 am here, so I might not be following things right, but doesn't the above mean you have to play funny games with what a function pointer is?
That is, the content of a function pointer (address taken) no longer match the actual function? That gives grief with things like static_call(), ftrace and other things that write call instructions instead of doing indirect calls.
| |