BUT I've got complains in the past from some users generating UUIDs for each forwarded request that they were seeing duplicates in their logs due to the lack of thread safety on random(), which made me work on an alternative. Thus I can easily imagine that equivalent applications that just want to assign a unique ID to an event that ends up in a log, and when such applications suffer a VM migration could face a similar problem that is not easy to address in userland.
I'd like to second that.
I sometimes need to duplicate a running VM, mostly in order to
debug stuff. Now both VMs run the same code with the same
pseudo-RNG, generating the same message IDs when they log
something. I've seen rejects on logs from the real VM because the
dupe got there first.
Owch.
A userspace RNG with a zapped VM_DROPPABLE page that re-initializes itself from the kernel RNG would solve this problem (and others).Thus a reasonable implementation seems to be
* implement VM_DROPPABLE (which I'd like to use for userspace
caching anyway)
* teach VM cloners, task migrators and whatnot not to copy pages marked thus
* add a RNG generation counter to the VDSO
* teach libc's getrandom() to use these
Yes this doesn't use the exact same implementation of random.c
that's in the kernel, but frankly I don't care about that.
-- -- regards -- -- Matthias Urlichs
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature