Messages in this thread | | | Date | Mon, 2 May 2022 21:41:57 +0200 | Subject | Re: [PATCH 2/2] random: add fork_event sysctl for polling VM forks | From | 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
| |