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]
Date:   Wed, 30 Nov 2022 11:51:57 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Jason A . Donenfeld" <Jason@...c4.com>,
        "Geert Uytterhoeven" <geert@...ux-m68k.org>
Cc:     linux-kernel@...r.kernel.org, patches@...ts.linux.dev,
        "Thomas Gleixner" <tglx@...utronix.de>,
        linux-crypto@...r.kernel.org, linux-api@...r.kernel.org,
        x86@...nel.org, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Adhemerval Zanella Netto" <adhemerval.zanella@...aro.org>,
        "Carlos O'Donell" <carlos@...hat.com>,
        "Florian Weimer" <fweimer@...hat.com>,
        "Christian Brauner" <brauner@...nel.org>
Subject: Re: [PATCH v10 2/4] arch: allocate vgetrandom_alloc() syscall number

On Wed, Nov 30, 2022, at 11:06, Jason A. Donenfeld wrote:
> On Wed, Nov 30, 2022 at 09:56:06AM +0100, Geert Uytterhoeven wrote:
>> Hi Jason,
>> 
>> On Tue, Nov 29, 2022 at 10:09 PM Jason A. Donenfeld <Jason@...c4.com> wrote:
>> > Add vgetrandom_alloc() as syscall 451 (or 561 on alpha) by adding it to
>> > all of the various syscall.tbl and unistd.h files.
>> >
>> > Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
>> 
>> Thanks for your patch!
>> 
>> What's the policy regarding adding syscall numbers for VDSO-related
>> syscalls on architectures that do not support VDSOs yet?
>
> I don't know exactly what the /policy/ is, but not wanting to rock the
> boat, the first iterations of this series only added it to x86. But then
> Arnd joined the thread and said I should add it to all of them all at
> once and separate that out into this commit, so that's what we have
> here. I think the idea is to keep syscall numbers synchronized these
> days between archs if possible.

Right, it shouldn't matter if the syscall has anything to do with vdso
or some other feature, the important bit is that this is an optional
syscall that may or may not exist in a kernel.

Adding every new syscall number to all architectures helps avoid
merge conflicts and keeps the numbers synchronized. It's entirely
plausible that this one gets enabled on an architecture that starts
out with the default -ENOSYS implementation, and has that
backported to 6.2 (or even older kernels in principle) for a
distro release, so it also makes sense to have it in the uapi
table as soon as we have fixed the number.

     Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ