Re: deconflicting new syscall numbers for 6.11

["Jason A. Donenfeld" <Jason@zx2c4.com>]

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@linux-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