How much of Golang functionality must be excluded in order to guarantee deterministic execution on a fixed system?
There are typical sources of nondeterminism 1. /dev/urandom 2. time We should include system variables here, but lets suppose we fix the system. One more source could be system files. Lets say we use chroot to jail the process. This should be done carefully: naive use does not exclude /dev/urandom , and as a result e.g. RSA key generation has access to randomness. But lets assume that we dealt with this issue. Also, the stack can be a source of randomness. In Golang, it is possible to get info about the stack. But lets say, we blocked these possibilities by forbidding the access to runtime. What else is there? At the moment it seems that to guarantee deterministic execution it is necessary to block access to modules: runtime syscall time crypto -- the parts that have to do with key generation os -- parts that get system variables and process information math/rand Which other standard modules can give rise to nondeterminism? It seems that modules -ioutil -bufio -most of os -strings -bytes are "nondeterminism safe". File info can be a source of nondeterminism - the last access time in nanoseconds. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/731a9430-6c0d-4f9f-87ec-75f833cc544fn%40googlegroups.com.
