Re: [RFC PATCH 0/2] Propagating reseed notifications to user space

[Alexander Graf]

[Resending in plain text only. Let's hope it reaches everyone this time :)]

Hey Jason!

On 04.09.23 16:42, Jason A. Donenfeld wrote:
> On Mon, Sep 04, 2023 at 03:44:48PM +0200, Babis Chalios wrote:
> > Hello all,
> >
> > On 23/8/23 11:01, Babis Chalios wrote:
> > > This is an RFC, so that we can discuss whether the proposed ABI works.
> > > Also, I'd like to hear people's opinion on the internal registration
> > > API, 8/24 split etc. If we decide that this approach works, I 'm happy
> > > to add documentation for it, with examples on how user space can make
> > > use of it.
> > Some time has passed since I sent this and I haven't received any
> > comments, so I assume people
> Nope. This still stands:
> https://lore.kernel.org/all/CAHmME9pxc-nO_xa=4+1CnvbnuefbRTJHxM7n817c_TPeoxzu_g@xxxxxxxxxxxxxx/


To recap, that email said:

> Just so you guys know, roughly the order of operations here are going to be:
>
> - vdso vgetrandom v+1
> - virtio fork driver
> - exposing fork events to userspace
>
> I'll keep you posted on those.

I don't quite understand both the relationship of vgetrandom to this nor 
how we could help. I understand how a VDSO vgetrandom could use 
primitives that are very similar (or maybe even identical) to this patch 
set.

What I'm missing is why there is a dependency between them. I don't 
expect user space PRNGs to disappear over night, especially given all 
the heavy lifting and architecture specific code that vDSOs require. So 
if we want to build a solution that allows user space to generically 
solve VM snapshots, we should strive to have a mechanism that works in 
today's environment in addition to making the vgetrandom call safe when 
it emerges.

The last revision of vgetrandom that I found was v14 from January. Is it 
still in active development? And if so, what is the status? The last 
fundamental comment I found in archives was this comment from Linus:


> This should all be in libc. Not in the kernel with special magic vdso
> support and special buffer allocations. The kernel should give good
> enough support that libc can do a good job, but the kernel should
> simply *not* take the approach of "libc will get this wrong, so let's
> just do all the work for it".

to which you replied

> That buffering cannot be done safely currently -- VM forks, reseeding
> semantics, and so forth. Again, discussed in the cover letter of the
> patch if you'd like to engage with those ideas.

My understanding is that this patch set solves exactly that problem in a 
way that is fully compatible with existing user space PRNGs and easy to 
consume as well as add support for in "Enterprise" systems for anyone 
who wishes to do so.

So, where is v15 without VM changes standing? And why exactly should we 
couple vgetrandom with atomic user space reseed notifications? :)


Thanks,

Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879