On Fri, Feb 28, 2025 at 12:53 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Wed, Feb 26, 2025 at 08:15:37PM +0800, Menglong Dong wrote: > > > 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@xxxxxxxxxxxxxx/ 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 >
