Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 18 Jul 2022 14:01:43 -0700 | Subject | Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation |
| |
On Mon, Jul 18, 2022 at 1:44 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > Yes, Peter and I came from avoiding a new compiler and the overhead for > everyone when putting the padding into the code. We realized only when > staring at the perf data that this padding in front of the function > might be an acceptable solution. I did some more tests today on different > machines with mitigations=off with kernels compiled with and without > that padding. I couldn't find a single test case where the result was > outside of the usual noise. But then my tests are definitely incomplete.
Well, it sounds like it most definitely isn't a huge and obvious problem.
> Yes, I know. But it was horrible enough to find the right spot in that > gcc maze. Then I was happy that I figured how to add the boolean > option. I let real compiler people take care of the rest. HJL??? > > And we need input from the Clang folks because their CFI work also puts > stuff in front of the function entry, which nicely collides.
Yeah, looking at the gcc sources (I have them locally because it helps with the gcc bug reports I've done over the years), that ASM_OUTPUT_FUNCTION_PREFIX is very convenient, but it's too late to do any inter-function alignment for, because it's already after the usual function-alignment output.
So I guess the padding thing is largely tied together with alignment of the function start, so that idea of having different padding and alignment bytes doesn't workl that well.
At least not in that ASM_OUTPUT_FUNCTION_PREFIX model, which is how the gcc patch ends up being so small.
Linus
| |