[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
