)]}' { "commit": "63ab5ea13b671cb60dd4b7cfde2bcae9d14c5a60", "tree": "dd3d7fbfd3184a2a3548577da5fc2a3821c1442d", "parents": [ "94f1c9379c3ed4b088718b35d0dd807d619d50c5" ], "author": { "name": "Benjamin Kaduk", "email": "bkaduk@akamai.com", "time": "Tue Jan 16 09:49:54 2018 -0600" }, "committer": { "name": "Ben Kaduk", "email": "kaduk@mit.edu", "time": "Wed Jan 31 12:25:28 2018 -0600" }, "message": "Revert the crypto \"global lock\" implementation\n\nConceptually, this is a squashed version of:\n\n Revert \"Address feedback\"\n\n This reverts commit 75551e07bd2339dfea06ef1d31d69929e13a4495.\n\nand\n\n Revert \"Add CRYPTO_thread_glock_new\"\n\n This reverts commit ed6b2c7938ec6f07b15745d4183afc276e74c6dd.\n\nBut there were some intervening commits that made neither revert apply\ncleanly, so instead do it all as one shot.\n\nThe crypto global locks were an attempt to cope with the awkward\nPOSIX semantics for pthread_atfork(); its documentation (the \"RATIONALE\"\nsection) indicates that the expected usage is to have the prefork handler\nlock all \"global\" locks, and the parent and child handlers release those\nlocks, to ensure that forking happens with a consistent (lock) state.\nHowever, the set of functions available in the child process is limited\nto async-signal-safe functions, and pthread_mutex_unlock() is not on\nthe list of async-signal-safe functions! The only synchronization\nprimitives that are async-signal-safe are the semaphore primitives,\nwhich are not really appropriate for general-purpose usage.\n\nHowever, the state consistency problem that the global locks were\nattempting to solve is not actually a serious problem, particularly for\nOpenSSL. That is, we can consider four cases of forking application\nthat might use OpenSSL:\n\n(1) Single-threaded, does not call into OpenSSL in the child (e.g.,\nthe child calls exec() immediately)\n\nFor this class of process, no locking is needed at all, since there is\nonly ever a single thread of execution and the only reentrancy is due to\nsignal handlers (which are themselves limited to async-signal-safe\noperation and should not be doing much work at all).\n\n(2) Single-threaded, calls into OpenSSL after fork()\n\nThe application must ensure that it does not fork() with an unexpected\nlock held (that is, one that would get unlocked in the parent but\naccidentally remain locked in the child and cause deadlock). Since\nOpenSSL does not expose any of its internal locks to the application\nand the application is single-threaded, the OpenSSL internal locks\nwill be unlocked for the fork(), and the state will be consistent.\n(OpenSSL will need to reseed its PRNG in the child, but that is\nan orthogonal issue.) If the application makes use of locks from\nlibcrypto, proper handling for those locks is the responsibility of\nthe application, as for any other locking primitive that is available\nfor application programming.\n\n(3) Multi-threaded, does not call into OpenSSL after fork()\n\nAs for (1), the OpenSSL state is only relevant in the parent, so\nno particular fork()-related handling is needed. The internal locks\nare relevant, but there is no interaction with the child to consider.\n\n(4) Multi-threaded, calls into OpenSSL after fork()\n\nThis is the case where the pthread_atfork() hooks to ensure that all\nglobal locks are in a known state across fork() would come into play,\nper the above discussion. However, these \"calls into OpenSSL after\nfork()\" are still subject to the restriction to async-signal-safe\nfunctions. Since OpenSSL uses all sorts of locking and libc functions\nthat are not on the list of safe functions (e.g., malloc()), this\ncase is not currently usable and is unlikely to ever be usable,\nindependently of the locking situation. So, there is no need to\ngo through contortions to attempt to support this case in the one small\narea of locking interaction with fork().\n\nIn light of the above analysis (thanks @davidben and @achernya), go\nback to the simpler implementation that does not need to distinguish\n\"library-global\" locks or to have complicated atfork handling for locks.\n\nReviewed-by: Kurt Roeckx \u003ckurt@roeckx.be\u003e\nReviewed-by: Matthias St. Pierre \u003cMatthias.St.Pierre@ncp-e.com\u003e\n(Merged from https://github.com/openssl/openssl/pull/5089)\n", "tree_diff": [ { "type": "modify", "old_id": "6fb135a758b4bc1418d6cf0fe7775894541e5f13", "old_mode": 33188, "old_path": "crypto/bio/b_addr.c", "new_id": "ab8e7ffd95a6b028a8161660f26c22297707796c", "new_mode": 33188, "new_path": "crypto/bio/b_addr.c" }, { "type": "modify", "old_id": "955be84e4105318df76280718a55d82607a219ff", "old_mode": 33188, "old_path": "crypto/bio/bio_meth.c", "new_id": "1c5d196239cdee9ce974a8c6aa6f5423fe8efa91", "new_mode": 33188, "new_path": "crypto/bio/bio_meth.c" }, { "type": "modify", "old_id": "8f6558422176e6ba689731ebd8f64cc8813a3a09", "old_mode": 33188, "old_path": "crypto/engine/eng_lib.c", "new_id": "db7717fc8b0904c908f4b33a7b173f91e4b54886", "new_mode": 33188, "new_path": "crypto/engine/eng_lib.c" }, { "type": "modify", "old_id": "c0bdbb8933549399bb3cc910b09fc998e2cadf23", "old_mode": 33188, "old_path": "crypto/err/err.c", "new_id": "a83da9b0e0418d315cf5d7aaf3577028c072bc2c", "new_mode": 33188, "new_path": "crypto/err/err.c" }, { "type": "modify", "old_id": "78162b5c092098163512a775c64300efb887e619", "old_mode": 33188, "old_path": "crypto/ex_data.c", "new_id": "538fdb1f1f63d3192aa226a3c95aef0ae7c7401c", "new_mode": 33188, "new_path": "crypto/ex_data.c" }, { "type": "modify", "old_id": "909775ab540b698c4d399fc49f0c3e7c52fad134", "old_mode": 33188, "old_path": "crypto/init.c", "new_id": "71accaa2ca600598cb4cfc3588c8e38a1fa3a1cf", "new_mode": 33188, "new_path": "crypto/init.c" }, { "type": "modify", "old_id": "b394de87ab8248b93dac418943642223c96a7979", "old_mode": 33188, "old_path": "crypto/mem_dbg.c", "new_id": "e11388224d586d8194d3f3c498bbb1638a985ec7", "new_mode": 33188, "new_path": "crypto/mem_dbg.c" }, { "type": "modify", "old_id": "8f4ae9c94a73ecaec39ea2b22e7a026ee530563e", "old_mode": 33188, "old_path": "crypto/mem_sec.c", "new_id": "4c010454955123c75ccfd465acf14f7d04936bbd", "new_mode": 33188, "new_path": "crypto/mem_sec.c" }, { "type": "modify", "old_id": "d0e8e05fe8789af373f42af955a66ca9d89de5bd", "old_mode": 33188, "old_path": "crypto/objects/o_names.c", "new_id": "73676445c1e43b2559bea6fc9610819675258385", "new_mode": 33188, "new_path": "crypto/objects/o_names.c" }, { "type": "modify", "old_id": "5e6bdceb1ed77c45fad3f7c6e4171c74650655aa", "old_mode": 33188, "old_path": "crypto/rand/drbg_lib.c", "new_id": "cb2f9e8d924a21e9492372d3ca9c17d79195eb1b", "new_mode": 33188, "new_path": "crypto/rand/drbg_lib.c" }, { "type": "modify", "old_id": "ab033566461ec76caf5aa285b79b07efa08b5ada", "old_mode": 33188, "old_path": "crypto/rand/rand_lib.c", "new_id": "20ac5839e66c199fd1427be1f03fcf936a70eb05", "new_mode": 33188, "new_path": "crypto/rand/rand_lib.c" }, { "type": "modify", "old_id": "987ca42f8cfbbb94e7fec6f5236851d5f0543ee4", "old_mode": 33188, "old_path": "crypto/store/store_register.c", "new_id": "85c38b84dd127e55e081ee6b880c45e530d530f4", "new_mode": 33188, "new_path": "crypto/store/store_register.c" }, { "type": "modify", "old_id": "5e9517d0fb00984ed83323e927eb27066d015d1c", "old_mode": 33188, "old_path": "include/openssl/crypto.h", "new_id": "478f9e2843488b5b7628a9f2815ac3bfc8e70ba8", "new_mode": 33188, "new_path": "include/openssl/crypto.h" }, { "type": "modify", "old_id": "536a3d24eeef81c97efaa6eef0947d4027239b3a", "old_mode": 33188, "old_path": "util/libcrypto.num", "new_id": "a2d03c602ae03b873d54c17a255d369264bde8ef", "new_mode": 33188, "new_path": "util/libcrypto.num" } ] }