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: <Zobtia2Zsaamh9KQ@1wt.eu>
Date: Thu, 4 Jul 2024 20:44:25 +0200
From: Willy Tarreau <w@....eu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>, jolsa@...nel.org,
        mhiramat@...nel.org, cgzones@...glemail.com, brauner@...nel.org,
        linux-kernel@...r.kernel.org, arnd@...db.de
Subject: Re: deconflicting new syscall numbers for 6.11

On Thu, Jul 04, 2024 at 10:55:46AM -0700, Linus Torvalds wrote:
> A trivial google for "rdrand library" finds lots of hits for things
> that then use the AES-NI instructions to whiten things etc.

As a userland developer, I can say that dealing with external libs for
low-level stuff, which themselves sometimes even come with their own
set of dependencies, is always a pain. There must be compelling reasons
for adding dependencies. It's reinforced when you have to deal with
long term support on your software that goes beyond the lib's.

And having to go through instruction support detection and open-coding
all that stuff with runtime fallbacks for older CPUs is also a pain. Not
to mention the cases where you run in VMs where features are there but
not listed or presented but slowly emulated.

I'm using a lot of arch-specific code at build time, I'm often fine with
detecting -ENOSYS at run time to fall back to an older implementation of
a syscall, but I've not crossed the barrier of runtime CPU features
detection which adds further burden and further fragments bug reports
between users.

Regarding VM migration, my code is not concerned because I'm not aware
of users migrating such VMs. BUT I've got complains in the past from
some users generating UUIDs for each forwarded request that they were
seeing duplicates in their logs due to the lack of thread safety on
random(), which made me work on an alternative. Thus I can easily
imagine that equivalent applications that just want to assign a unique
ID to an event that ends up in a log, and when such applications suffer
a VM migration could face a similar problem that is not easy to address
in userland.

In my opinion, abstracting the hardware is the role of the kernel. If
getrandom() is fast enough for my uses, why not. If it's not, I find
value in having a much faster proposal that offers the same API to all
applications without each having to reinvent the wheel. I can't judge
on the merits of vgetrandom() vs getrandom() though. But to give you an
idea, years ago for portability reasons (random() thread safety, multiple
OS support, performance), I ended up writing my own xoroshiro128 generator
to address multiple problems at once and I must confess I was a bit sad
to see that randoms remain so little portable between operating systems
and their various versions, and that the work left to be done for users
is non trivial.

I can imagine that users with higher expectations than mine would want
to adopt vgetrandom() when available.

Now would I replace my existing RNG with this new syscall when it gets
widely available ? Maybe, if it brings some value. It's easy enough to
deal with two code branches, one with the new, optimal syscall, and the
legacy generic fallback.

Hoping this matches the type of feedback you were looking for.

Willy