Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 18 Jul 2022 17:11:27 -0700 | Subject | Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation |
| |
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?
Linus
| |