linux-kernel - Re: deconflicting new syscall numbers for 6.11

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: <cb2f5427-521c-40eb-90fd-f253b41d5422@app.fastmail.com>
Date: Fri, 05 Jul 2024 10:32:54 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>
Cc: "Jason A . Donenfeld" <Jason@...c4.com>, "Jiri Olsa" <jolsa@...nel.org>,
 "Masami Hiramatsu" <mhiramat@...nel.org>, cgzones@...glemail.com,
 "Christian Brauner" <brauner@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: deconflicting new syscall numbers for 6.11

On Fri, Jul 5, 2024, at 00:07, Linus Torvalds wrote:
> On Thu, 4 Jul 2024 at 14:45, Arnd Bergmann <arnd@...db.de> wrote:
>>
>> It's not random, it's all the architectures: the ones that
>> don't have a syscall.tbl file are the ones that use the table
>> in include/uapi/asm-generic/unistd.h.
>
> Ok.
>
> I think it's bogus to reseve system calls for everybody even when it
> makes no sense.

I see. Just to make sure: do you think it's ok to still
reserve system call numbers everywhere if they are used
on most architectures? I posted a series yesterday to
convert include/asm-generic/uapi/unistd.h into the syscall.tbl
format, and I did this change for clone3:

https://lore.kernel.org/lkml/20240704143611.2979589-8-arnd@kernel.org/

The reasoning here is that we want this to be available
everywhere but there are four architectures still missing
it, and having the macro defined in the generated unistd.h
avoids a special case.

On the other hand, I left memfd_secret a special case since
that one is only implemented on one architecture using the
generic table.

> But it's also pretty moot, since I think the whole system call has to go away.
>
> All it is is an odd wrapper around mmap() anyway, and it's a useful
> enough thing *outside* of getrandom() that I pretty much guarantee it
> will be used for other things than vgetrandom anyway.

Right.

    Arnd