Re: [PATCH 2/2] random: add fork_event sysctl for polling VM forks

[Alexander Graf]

On 02.05.22 21:27, Jason A. Donenfeld wrote:
> On Mon, May 02, 2022 at 08:56:05PM +0200, Alexander Graf wrote:
> > On 02.05.22 20:46, Jason A. Donenfeld wrote:
> > > On Mon, May 02, 2022 at 08:34:38PM +0200, Alexander Graf wrote:
> > > > Michael, since we already changed the CID in the spec, can we add a
> > > > property to the device that indicates the first 4 bytes of the UUID will
> > > > always be different between parent and child?
> > > >
> > > > That should give us the ability to mmap the vmgenid directly to user
> > > > space and act based on a simple u32 compare for clone notification, no?
> > > That is not a good idea. We want an _additional_ 4 bytes, so that we can
> > > keep the first 16 bytes (128 bits) as a kernel space secret.
> >
> > An additional 4 bytes would be an additional 4kb (or 64kb on ARM) page.
> > Do we really rely on these 16 bytes to reseed after clone? If so, we'd
> > need to bite the bullet and provide an additional page, yes.
> Ugh, you're right; memory mapping is pages. The other option would be
> relying on RDRAND (both existing and being trusted by the user etc), but
> generally people aren't too jazzed about that. We pretty much have to
> assume that the existing pool is compromised, since people share cloned
> VMs casually. The 128-bit vmgenid is a nice input to have.


I can see the merit. So yes, we'd want a second function to the 
VM_GEN_COUNTER device in addition to "ADDR" that - in a fully user space 
mappable separate page - gives us a 32-bit vmgenid that is guaranteed to 
be different from the previous one.


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