Implement keysinuse forking handlers for 1.9

[mamckee]

This PR ports PR #154 to the 1.9 branch to support keysinuse by forking processes.

Most processes call exec or a similar function to start a child process after calling fork, where the SymCrypt provider is reloaded and KeysInUse is started again. However, some applications such as nginx continue to run without calling exec. In this case, the KeysInUse logging thread needs to be recreated in the child process. The logging thread cannot hold any locks going into the fork.

There are four scenarios to consider:

• Single threaded parent (excluding logging thread) -> fork and no call to exec (e.g. nginx)
  • Supported
  • Synchronization locks between logging thread and main thread need to be held by the main thread in the fork callbacks
  • All pending keysinuse infos need to be reset and removed to avoid duplication and misattribution
• Single threaded parent (excluding logging thread) -> fork and call exec
  • Supported
  • Not expected to call OpenSSL functions until exec, but falls under the same story as above
• Multi threaded parent -> fork and no call to exec
  • Not Supported
  • The child should only call async safe functions after fork
  • OpenSSL is not async safe and explicitly does not support being called after fork by a multi-threaded program.
• Multi threaded parent -> fork and call exec
  • Limited Support
  • Parent cannot call any OpenSSL functions that trigger keysinuse until exec. This change will not regress this scenario

[Copilot]

Pull request overview

Ports fork-handling support for KeysInUse to the 1.9 branch so that non-exec() forked child processes (e.g., nginx workers) can safely recreate the KeysInUse logging thread/state.

Changes:

• Adds pthread_atfork() prepare/parent/child handlers to quiesce KeysInUse state and restart logging in the child when needed.
• Introduces a global “pending” KeysInUse stack to avoid realloc/leaks across fork-related logging thread recreation.
• Minor cleanup: initialize public-key buffers to defaults and fix indentation.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
SymCryptProvider/src/p_scossl_keysinuse.c	Adds atfork handlers and global pending stack; adjusts init/teardown and logging-thread cleanup to support forked children.
SymCryptProvider/src/p_scossl_rsa.c	Initializes KeysInUse public-key buffer variables to avoid uninitialized use.
SymCryptProvider/src/p_scossl_ecc.c	Fixes indentation and initializes KeysInUse public-key buffer variables.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 11 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 9 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jasjivsingh-corp]

what about just using /proc/self/status instead and check it against == 2? that would be reliable enough

[mamckee]

So, I originally went with this approach, but it does require parsing the file. /proc/self/stat would probably be faster than parsing /proc/self/status but would still be similar parsing logic.

I think we should be really selective to when this gets enabled (i.e. we're 100% confident the only threads running are the main thread and the logging thread). If the logging thread crashes or is terminated for whatever reason, and we just check threads == 2, we could theoretically try to start keysinuse logging in the child process since is_logging would be true. I don't think this is a very common scenario but I'd rather be conservative with enabling this in a child process.