Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 18 Jul 2022 18:02:10 -0700 | Subject | Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation |
| |
On Mon, Jul 18, 2022 at 5:23 PM Peter Zijlstra <peterz@infradead.org> wrote: > > 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?
Yes, but probably no more than compilers already do.
On x86, function pointers are simple, and just pointers to the first instruction of the function.
But that's actually not true in general, and several other architectures have *much* more complicated function pointers, where they are pointers to special "function descriptor blocks" etc.
So I bet gcc has all that infrastructure in place anyway.
And the whole "use a different address for a direct call than for an indirect call" is still much simpler than having an actual separate function descriptor thing.
At worst, you'd actually always generate the thunk for the indirect call case, and let the linker kill unused cases. The compiler wouldn't even have to know about the two cases, except to use a different names for the direct call case.
Do I claim it would be *pretty*? No. But I bet the existing CFI patches already do things like this anyway.
(I have llvm sources on my machine too, because I used to build my own clang from source back when I was testing the asm goto stuff. But unlike gcc, I've never really *looked* at llvm, so I'm not familiar with it at all, and I'm not going to try to figure out what the CFI code actually does, and instead just handwave widely while saying "I bet it already does this".)
Linus
| |