On Fri, Feb 28, 2025 at 12:53 AM Peter Zijlstra [off-list ref] wrote:

On Wed, Feb 26, 2025 at 08:15:37PM +0800, Menglong Dong wrote:

quoted

In x86, we need 5-bytes to prepend a "mov %eax xxx" insn, which can hold
a 4-bytes index. So we have following logic:

1. use the head 5-bytes if CFI_CLANG is not enabled
2. use the tail 5-bytes if MITIGATION_CALL_DEPTH_TRACKING is not enabled
3. compile the kernel with extra 5-bytes padding if
   MITIGATION_CALL_DEPTH_TRACKING and CFI_CLANG are both enabled.

3) would result in 16+5 bytes padding, what does that do for alignment?

Hi Peter, thank you for your reply~

Yeah, it will make the function not 16 byte aligned, and this is
the most pointer that I hesitate in.

In this link, I tested the performance with 16+5 bytes padding,
and it seems that the performance is not impacted:

https://lore.kernel.org/bpf/CADxym3af+CU5Mx8myB8UowdXSc3wJOqWyH4oyq+eXKahXBTXyg@mail.gmail.com/ (local)

However, it may have other effects if the function is unaligned.
I don't know either. :/

Do you have any advice here? Such as, we'd better make the
padding 32 bytes instead in case 3 :/

Functions should be 16 byte aligned.

Also, did you make sure all the code in arch/x86/kernel/alternative.c
still works? Because adding extra padding in the CFI_CLANG case moves
where the CFI bytes are emitted and all the CFI rewriting code goes
sideways.

I tested it a little by enabling CFI_CLANG and the extra 5-bytes
padding. It works fine, as mostly CFI_CLANG use
CONFIG_FUNCTION_PADDING_BYTES to find the tags. I'll
do more testing on CFI_CLANG to make sure everything goes
well.

Thanks!
Menglong Dong