linux-kernel - Re: [PATCH v2 1/4] alpha/uapi: do not expose kernel-only stack frame structures

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: <Z6D5UyV9Z0demt40@minute>
Date: Mon, 3 Feb 2025 18:13:55 +0100
From: Ivan Kokshaysky <ink@...een.parts>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Richard Henderson <richard.henderson@...aro.org>,
	Matt Turner <mattst88@...il.com>, Oleg Nesterov <oleg@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>, Arnd Bergmann <arnd@...db.de>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Magnus Lindholm <linmag7@...il.com>,
	John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
	linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH v2 1/4] alpha/uapi: do not expose kernel-only stack frame
 structures

On Sun, Feb 02, 2025 at 05:39:52PM +0000, Maciej W. Rozycki wrote:
>  What do you think about providing arch/alpha/include/asm/bpf_perf_event.h 
> instead with either a dummy definition of `bpf_user_pt_regs_t', or perhaps 
> one typedef'd to `struct sigcontext' (as it seems to provide all that's 
> needed), and then reverting to v1 of arch/alpha/include/uapi/asm/ptrace.h 
> (and then just copying the contents of arch/alpha/include/asm/ftrace.h 
> over rather than leaving all the useless CPP stuff in) so that we don't 
> have useless `struct pt_regs' exported at all?

Probably that's the right thing to do. However, it implies adding

#elif defined(__alpha__)
#include "../../arch/alpha/include/uapi/asm/bpf_perf_event.h"

in tools/include/uapi/asm/bpf_perf_event.h. I'm afraid that will
result in too many loosely related changes for this patch series.

I'm starting to think that the best way for the time being is to keep
uapi/asm/ptrace.h and apply the fix there (i.e. revert to v0 patch
posted on linux-alpha). And mention the pt_regs vs uapi issue in the
commit message, of course, to deal with it later. Your opinion?

Ivan.