linux-kernel - Re: linux-next: manual merge of the vfs-brauner tree with the asm-generic tree

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: <Zo04ZYIEyayrvBYz@krava>
Date: Tue, 9 Jul 2024 15:17:25 +0200
From: Jiri Olsa <olsajiri@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Jiri Olsa <olsajiri@...il.com>, Stephen Rothwell <sfr@...b.auug.org.au>,
	Christian Brauner <brauner@...nel.org>,
	Christian Göttsche <cgzones@...glemail.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-next <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the vfs-brauner tree with the
 asm-generic tree

On Tue, Jul 09, 2024 at 02:58:06PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 9, 2024, at 14:42, Jiri Olsa wrote:
> > On Tue, Jul 09, 2024 at 02:20:26PM +0200, Arnd Bergmann wrote:
> >> On Tue, Jul 9, 2024, at 13:53, Jiri Olsa wrote:
> >> > On Tue, Jul 09, 2024 at 01:44:34PM +0200, Arnd Bergmann wrote:
> >> >
> >> >> Though I'm still not sure what uretprobe is only added
> >> >> to half the architectures at the moment. There is a chance
> >> >> we need a different conditional for it than '64'.
> >> >
> >> > uretprobe is defined only for x86_64, not sure what that means
> >> > for scripts/syscall.tbl though
> >> 
> >> I meant you hooked it up unconditionally for all architectures
> >> using the old method, i.e. arc, arm64, csky, hexagon, loongarch64,
> >> nios2, openrisc, riscv32, riscv64, and xtensa in addition
> >> to x86-64, but not for the other ABIs: alpha, arm32, m68k,
> >> microblaze, mips-o32, mips-n32, mips64, nios2, parisc32, parisc64,
> >> powerpc32, powerpc64, powerpc-spu, s390-31, s390-64, sh,
> >> sparc32, sparc64, x86-32 and x86-x32.
> >> 
> >> If that is not the list you had intended, do you have a list
> >> of which architectures actually have the required hardware
> >> to hook it up? It would be good to do this correctly from
> >> the start so we don't rely on architecture maintainers assigning
> >> the numbers individually.
> >
> > hum, so it's hooked in:
> >   190fec72df4a uprobe: Wire up uretprobe system call
> >
> > and the intention is to have it ONLY for x86_64 (as stated above),
> > if that's not what happened I need to fix it, please let me know
> > what's the problem
> 
> If this cannot be used on any other architectures, I would
> suggest adding it to the architecture specific list instead,
> probably number #335, which is unused on x86-64.
> 
> I was under the assumption that this would theoretically be
> useful for non-x86 architectures in the future, in which

yes, at the moment uretprobe is implemented on x86_64 only,
but it could be perhaps implemented on other archs in future

> case you should reserve the same syscall number everywhere

hum, is that necessary? I don't mind, but I don't see why it
should be the same number on another archs?

> now and rely the stub in kernel/sys_ni.c for those that are
> missing the implementation.

thanks,
jirka