linux-kernel - Re: [PATCH bpf-next v2] add function metadata support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADxym3YCZ5dqXMFesNaAF_Z2EWWCj0bJyKQ+BnNw2c=g39CRFA@mail.gmail.com>
Date: Fri, 28 Feb 2025 17:53:07 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: rostedt@...dmis.org, mark.rutland@....com, alexei.starovoitov@...il.com, 
	catalin.marinas@....com, will@...nel.org, mhiramat@...nel.org, 
	tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, 
	mathieu.desnoyers@...icios.com, nathan@...nel.org, ndesaulniers@...gle.com, 
	morbo@...gle.com, justinstitt@...gle.com, dongml2@...natelecom.cn, 
	akpm@...ux-foundation.org, rppt@...nel.org, graf@...zon.com, 
	dan.j.williams@...el.com, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, 
	bpf@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH bpf-next v2] add function metadata support

On Fri, Feb 28, 2025 at 12:53 AM Peter Zijlstra <peterz@...radead.org> 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@mail.gmail.com/

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

>