Messages in this thread | | | Date | Mon, 18 Jul 2022 23:18:40 +0200 | From | Peter Zijlstra <> | Subject | Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation |
| |
On Mon, Jul 18, 2022 at 10:44:14PM +0200, Thomas Gleixner wrote:
> > 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.
Right, I need to go look at the latest kCFI patches, that sorta got side-tracked for working on all the retbleed muck :/
Basically kCFI wants to preface every (indirect callable) function with:
__cfi_\func: int3 movl $0x12345678, %rax int3 int3 \func: endbr \func_direct:
Ofc, we can still put the whole:
sarq $5, PER_CPU_VAR(__x86_call_depth); jmp \func_direct
thing in front of that. But it does somewhat destroy the version I had that only needs the 10 bytes padding for the sarq.
| |