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: <87v81txjb7.ffs@tglx>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ