Ahh, not really - while the process thing the author describes is real - what you're saying is that any two processes show the same values, and that isn't the case. the bad guy needs to control one process to read the values in a useful way, have it exit, and be able to maniuplate the system by killing or creating processes until his intended victim comes up on his selected PID. While that's far from impossible to do (just as the author's program does it) It is likely going to imply enough access to your system by the attacker that you're already pretty much p0wned.
Not sure how a library is going to keep a caller from closing a descriptor - I've certainly seen people attempt to close them all in code before a fork, but that's probably pathological. However that doesn't work across a re-exec, which would also be good practice in many situations (ASLR) - so having to keep a descriptor open to do this would actually discourage secure programming practices because the library would screw you then. What's here will work in that case from the look of it. (assuming sysctl is there, or the voodoo isn't really that bad, I can't tell myself yet... still looking)
Even though it looks like it won't get called, I'm wondering how bad the voodoo is? Anyone looked at what it is spitting into that hash function? How predictable are those clocks as they change between the memory fetches. Will Linux have predictable memory access times where those pages land?
"If that's the case?" - Didn't you read the code? :) Sounds like you would prefer no stirring of any new entropy after you chroot... Looks to me like they're trying to require that additional entropy be available, always. (and if you don't have a completely hacked up kernel sysctl is still there..) - maybe we might get something better before it (sysctl) goes away for real instead of just in c-library-du-jour.
You can't simply seed it before a chroot. Look at the code. chacha adds entropy periodically and folds it in. You need entropy in the chroot. The author should probably read 10 lines below the same code he posted in the article. While I'd love to see a solution for this particular contrived example, considering in the much more common use cases it actually is more secure than OpenSSL's. Especially so if your kernel has sysctl in it.