Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation | Date | Mon, 18 Jul 2022 22:44:14 +0200 |
| |
On Mon, Jul 18 2022 at 12:51, Linus Torvalds wrote: > On Mon, Jul 18, 2022 at 12:30 PM Thomas Gleixner <tglx@linutronix.de> wrote: >> >> Let the compiler add a 16 byte padding in front of each function entry >> point and put the call depth accounting there. That avoids calling out >> into the module area and reduces ITLB pressure. > > Ooh. > > I actually like this a lot better. > > Could we just say "use this instead if you have SKL and care about the issue?" > > I don't hate your module thunk trick, but this does seem *so* much > simpler, and if it performs better anyway, it really does seem like > the better approach.
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.
> And people and distros who care would have an easy time adding that > simple compiler patch instead. > > I do think that for generality, the "-mforce-function-padding" option > should perhaps take as an argument how much padding (and how much > alignment) to force: > > -mforce-function-padding=5:16 > > would force 5 bytes of minimum padding, and align functions to 16 > bytes. It should be easy to generate (no more complexity than your > current one) by just making the output do > > .skip 5,0xcc > .palign 4,0xcc > > and now you can specify that you only need X bytes of padding, for example.
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.
Thanks,
tglx
| |