On Wed, Mar 02, 2022 at 04:14:56PM +0100, Jason A. Donenfeld wrote: > Hi Michael, > > On Wed, Mar 2, 2022 at 3:46 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > I just don't see how "value changed while it was read" is so different > > from "value changed one clock after it was read". Since we don't detect > > the latter I don't see why we should worry about the former. > > The "barrier" is at the point where the plaintext has been chosen AND > the nonce for a given keypair has been selected. So, if you have > plaintext in a buffer, and a key in a buffer, and the nonce for that > encryption in a buffer, and then after those are all selected, you > check to see if the vmgenid has changed since the birth of that key, > then you're all set. If it changes _after_ that point of check (your > "one clock after"), it doesn't matter: you'll just be > double-transmitting the same ciphertext, which is something that flaky > wifi sometimes does _anyway_ (and attackers can do intentionally), so > network protocols already are resilient to replay. This is the same > case you asked about earlier, and then answered yourself, when you > were wondering about reaching down into qdiscs. > > Jason So writing some code: 1: put plaintext in a buffer put a key in a buffer put the nonce for that encryption in a buffer if vm gen id != stored vm gen id stored vm gen id = vm gen id goto 1 I think this is race free, but I don't see why does it matter whether we read gen id atomically or not. -- MST
