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: <Zobt_M91PEnVobML@zx2c4.com>
Date: Thu, 4 Jul 2024 20:46:20 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: 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

Hi Linus,

On Thu, Jul 04, 2024 at 11:35:12AM -0700, Linus Torvalds wrote:
> On Thu, 4 Jul 2024 at 11:18, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > See what my argument is? I suspect _strongly_ that this is all
> > completely over-engineered based on theoretical grounds that aren't
> > actually practical grounds.
> 
> I also have a separate suggestion: I'm more than happy to do something
> *MUCH SIMPLER*.
> 
> If people want just generation counts, we can give them generation

I addressed this in the cover letter:

| How do we rectify this? By putting a safe implementation of getrandom()
| in the vDSO, which has access to whatever information a
| particular iteration of random.c is using to make its decisions. I use
| that careful language of "particular iteration of random.c", because the
| set of things that a vDSO getrandom() implementation might need for making
| decisions as good as the kernel's will likely change over time. This
| isn't just a matter of exporting certain *data* to userspace. We're not
| going to commit to a "data API" where the various heuristics used are
| exposed, locking in how the kernel works for decades to come, and then
| leave it to various userspaces to roll something on top and shoot
| themselves in the foot and have all sorts of complexity disasters.
| Rather, vDSO getrandom() is supposed to be the *same exact algorithm*
| that runs in the kernel, except it's been hoisted into userspace as
| much as possible. And so vDSO getrandom() and kernel getrandom() will
| always mirror each other hermetically.

random.c has a long history of exposing lots of particulars that we've
had to stub out. Enough of that. It's far better to have a function (not
a piece of data!) that uses the *exact same algorithm* and hence has the
exact same guarantees as random.c, and the kernel can keep those in
sync.

Jason