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