)]}' { "commit": "b8f760191e5ca6e633e8cca150b4090ddc8d6bf7", "tree": "e99c70203695fe178387016697c04f05d9dad8c0", "parents": [ "4ca15d5dcbe6e8051a4654df7c971ea8307abfe0" ], "author": { "name": "Adam Langley", "email": "agl@google.com", "time": "Tue Oct 15 12:31:14 2019 -0700" }, "committer": { "name": "Adam Langley", "email": "agl@google.com", "time": "Tue Oct 15 13:26:20 2019 -0700" }, "message": "Fix GRND_NONBLOCK flag when calling getrandom.\n\nI screwed up in 56b6c714c9 and got the direction of this condition\nbackwards. This doesn\u0027t cause a security problem because:\n a) wait_for_entropy will ensure that the pool is initialised.\n b) if GRNG_NONBLOCK is set when not expected, any EAGAIN will\n cause an abort anyway.\n\nHowever, when coupled with opportunistic entropy collection on platforms\nwith RDRAND, this could cause an unexpected blocking getrandom call.\n\nThis this change, `strace -e getrandom bssl rand 1` shows two getrandom\ncalls with GRNG_NONBLOCK set, as expected. (The first being the probe to\ncheck whether the kernel supports getrandom, and the second being the\nopportunistic entropy gathering to augment RDRAND.)\n\nChange-Id: I98ed1cef90df510f24cf2df1fba9b886fcbf3355\n", "tree_diff": [ { "type": "modify", "old_id": "33c0b0319740d3aa124d70a38e3239a7debd9103", "old_mode": 33188, "old_path": "crypto/fipsmodule/rand/urandom.c", "new_id": "4a60eb2f85be268cedbbdeca9b9d08b2429d9a61", "new_mode": 33188, "new_path": "crypto/fipsmodule/rand/urandom.c" } ] }