Async-signal-safe API to clear `EVP_PKEY` contents
#30.057 geöffnet am 17. Feb. 2026
Repository-Metriken
- Stars
- (30.157 Stars)
- PR-Merge-Metriken
- (Keine gemergten PRs in 30 T)
Beschreibung
Background
In containerized environments, applications often cannot rely on the host’s default core-dump configuration. Core dump behavior is controlled by host-level limits and kernel settings, which may be restricted by the container runtime. As a result, some applications install fatal signal handlers and generate crash artifacts (e.g. core dumps or structured crash reports) in userspace.
When a process receives a fatal signal (e.g. SIGSEGV, SIGABRT) and handles it via sigaction, applications may need to ensure that private key material is not recoverable from those crash artifacts.
Calling EVP_PKEY_free() from a signal handler is not safe, as it may eventually call free(), which is not async-signal-safe and can result in undefined behavior. Currently, there is no supported way to reliably wipe the contents of an EVP_PKEY in a signal-safe context.
Proposal
Introduce an async-signal-safe API to clear sensitive key material without freeing memory, e.g.:
int EVP_PKEY_clear(EVP_PKEY *pkey);
Requirements:
- Zero all sensitive key material associated with the
EVP_PKEY - Must not call
free()or other non–async-signal-safe functions - Must not allocate memory or take locks
- Safe to call from a fatal signal handler
- Leave the object allocated but in an cleared/inert state
The goal is zeroization only, not object destruction.
Rationale
- Reduces risk of private key exposure via core dumps
- Enables safer crash handling in security-sensitive applications
- Avoids undefined behavior/crash from calling non–signal-safe APIs
MADV_DONTDUMPor similar mechanisms cannot be used
We would appreciate feedback on whether such an API would be acceptable, or whether there are alternative approaches that better align with OpenSSL’s design.