linux-kernel - Re: [PATCH v18 2/5] random: add vgetrandom

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: Fri, 28 Jun 2024 15:56:12 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Jason A. Donenfeld" <Jason@...c4.com>, Aleksa Sarai <cyphar@...har.com>
Cc: linux-kernel@...r.kernel.org, patches@...ts.linux.dev,
 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>, Arnd Bergmann <arnd@...db.de>, Jann
 Horn <jannh@...gle.com>, Christian Brauner <brauner@...nel.org>, David
 Hildenbrand <dhildenb@...hat.com>
Subject: Re: [PATCH v18 2/5] random: add vgetrandom_alloc() syscall

Jason!

On Thu, Jun 20 2024 at 14:18, Jason A. Donenfeld wrote:
> On Wed, Jun 19, 2024 at 07:13:26PM -0700, Aleksa Sarai wrote:
>> Then again, I guess since libc is planned to be the primary user,
>> creating a new syscall in a decade if necessary is probably not that big
>> of an issue.
>
> I'm not sure going the whole big struct thing is really necessary, and
> for an additional reason: this is only meant to be used with the vDSO
> function, which is also coupled with the kernel. It doesn't return
> information that's made to be used (or allowed to be used) anywhere
> else. So both the vdso code and the syscall code are part of the same
> basic thing that will evolve together. So I'm not convinced extensible
> struct really makes sense for this, as neat as it is.
>
> If there's wide consensus that it's desirable, in contrast to what I'm
> saying, I'm not vehemently opposed to it and could do it, but it just
> seems like massive overkill and not at all necessary. Things are
> intentionally as simple and straightforward as can be.

Right, but the problem is that this is a syscall, so people are free to
explore it even without the vdso part. Now when you want to change it
later then you are caught in the no-regression trap.

So making it extensible with backwards compability in place (add the
unused flag field and check for 0) will allow you to expand without
breaking users.

Thanks,

        tglx