Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation

[Peter Zijlstra]

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.