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: <736fde6a-7b2a-4920-af1e-1ad2358db785@app.fastmail.com>
Date: Tue, 09 Jul 2024 14:58:06 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jiri Olsa" <olsajiri@...il.com>
Cc: "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 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
case you should reserve the same syscall number everywhere
now and rely the stub in kernel/sys_ni.c for those that are
missing the implementation.

     Arnd