netdev - Re: [PATCH v4 4/4] arm64: implement per-function metadata storage for arm64

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: <CADxym3Z76bm9wXPjX=9c95eZtWjODwz70xN1KUR92NuC6vzrwg@mail.gmail.com>
Date: Tue, 4 Mar 2025 09:21:15 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: Sami Tolvanen <samitolvanen@...gle.com>
Cc: peterz@...radead.org, 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, ast@...nel.org, 
	daniel@...earbox.net, andrii@...nel.org, martin.lau@...ux.dev, 
	eddyz87@...il.com, yonghong.song@...ux.dev, john.fastabend@...il.com, 
	kpsingh@...nel.org, sdf@...ichev.me, jolsa@...nel.org, davem@...emloft.net, 
	dsahern@...nel.org, mathieu.desnoyers@...icios.com, nathan@...nel.org, 
	nick.desaulniers+lkml@...il.com, morbo@...gle.com, kees@...nel.org, 
	dongml2@...natelecom.cn, akpm@...ux-foundation.org, riel@...riel.com, 
	rppt@...nel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, 
	bpf@...r.kernel.org, netdev@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH v4 4/4] arm64: implement per-function metadata storage for arm64

On Tue, Mar 4, 2025 at 5:40 AM Sami Tolvanen <samitolvanen@...gle.com> wrote:
>
> On Mon, Mar 03, 2025 at 09:28:37PM +0800, Menglong Dong wrote:
> > The per-function metadata storage is already used by ftrace if
> > CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS is enabled, and it store the pointer
> > of the callback directly to the function padding, which consume 8-bytes,
> > in the commit
> > baaf553d3bc3 ("arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS").
> > So we can directly store the index to the function padding too, without
> > a prepending. With CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS enabled, the
> > function is 8-bytes aligned, and we will compile the kernel with extra
> > 8-bytes (2 NOPS) padding space. Otherwise, the function is 4-bytes
> > aligned, and only extra 4-bytes (1 NOPS) is needed.
> >
> > However, we have the same problem with Mark in the commit above: we can't
> > use the function padding together with CFI_CLANG, which can make the clang
> > compiles a wrong offset to the pre-function type hash. He said that he was
> > working with others on this problem 2 years ago. Hi Mark, is there any
> > progress on this problem?
>
> I don't think there's been much progress since the previous
> discussion a couple of years ago. The conclusion seemed to be
> that adding a section parameter to -fpatchable-function-entry
> would allow us to identify notrace functions while keeping a
> consistent layout for functions:
>
> https://lore.kernel.org/lkml/Y1QEzk%2FA41PKLEPe@hirez.programming.kicks-ass.net/

Thank you for your information, which helps me a lot.
I'll dig deeper to find a way to keep CFI working together
with this function.

Thanks!
Menglong Dong

>
> Sami