Hi, 16 janvier 2023 à 20:50 "Andy Lutomirski" <luto@xxxxxxxxxxxxxx> a écrit: > > On Jan 13, 2023, at 7:16 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > > On 1/12/23 11:55, Yann Droneaud wrote: > > > 12 janvier 2023 à 18:07 "Jason A. Donenfeld" <Jason@xxxxxxxxx> a écrit: > > > > > > > Sorry Yann, but I'm not interested in this approach, and I don't think > > reviewing the details of it are a good allocation of time. I don't > > want to lock the kernel into having specific reseeding semantics that > > are a contract with userspace, which is what this approach does. > > > > > > > > This patch adds a mean for the kernel to tell userspace: between the > > > last time you call us with getrandom(timestamp,, GRND_TIMESTAMP), > > > something happened that trigger an update to the opaque cookie given > > > to getrandom(timestamp, GRND_TIMESTAMP). When such update happen, > > > userspace is advised to discard buffered random data and retry. > > > The meaning of the timestamp cookie is up to the kernel, and can be > > > changed anytime. Userspace is not expected to read the content of this > > > blob. Userspace only acts on the length returned by getrandom(,, GRND_TIMESTAMP): > > > -1 : not supported > > > 0 : cookie not updated, no need to discard buffered data > > > >0 : cookie updated, userspace should discard buffered data > > > For the cookie, I've used a single u64, but two u64 could be a better start, > > > providing room for implementing improved behavior in future kernel versions. > > > > > > > Please just let me iterate on my original patchset for a little bit, > > without adding more junk to the already overly large conversation. > > > > > > > > I like the simplicity of my so called "junk". It's streamlined, doesn't > > > require a new syscall, doesn't require a new copy of ChaCha20 code. > > > I'm sorry it doesn't fit your expectations. > > > > > > > > > Why would anything more than a 64-bit counter be ever necessary? It only needs to be incremented. > > > > This is completely broken with CRIU or, for that matter, with VM forking. > Which raise the question of the support of CRIU with Jason's vDSO proposal. AFAIK CRIU handle vDSO[1] by interposing symbols so that, on restore, the process will call the interposed functions, which will resolve the new vDSO's functions. vgetrandom_alloc() would have been called before the checkpoint, allocating one opaque state of size x. After the restore, the vDSO's getrandom() would be given this opaque state, expecting it having size y. As the content of the opaque state should have been cleared per MADV_WIPEONFORK, there's nothing in the state that could help vDSO's getrandom() to achieve backward compatibility. I think backward compatibility can be achieved by adding an opaque state size argument to vDSO's getrandom(). What to think Jason ? [1] https://criu.org/Vdso Regards. -- Yann Droneaud OPTEYA
