Re: deconflicting new syscall numbers for 6.11

Matthias Urlichs
2024-07-05T07:33:20Z

[-- Attachment #1.1.1: Type: text/plain, Size: 1463 bytes --]

On 04.07.24 20:44, Willy Tarreau wrote:
> 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 #1.1.2: Type: text/html, Size: 1944 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]