You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should consider phasing out secstr for our own "secured memory" implementation, with full support for other primitives for isolating memory pages to support different OSes:
Linux - typical support for mlock and zeroing, but also thinking MFD_SECRET_*, as posed here to further isolate sensitive memory from kernel space and even cache. Have not seen a merge upstream to a new revision yet, but interesting to think about.
macOS - mlock again, but also potentially pushing support for Secure Enclave storage, which will requiring signing rather than our current symmetric encryption.
Windows - CryptProtectMemory and SecureZeroMemory for explicit zeroing.
Backing to other native "keyring" implementations (Credential Manager, macOS Keychain) are also interesting and provides security and isolation for free(-ish).
The text was updated successfully, but these errors were encountered:
We should consider phasing out
secstr
for our own "secured memory" implementation, with full support for other primitives for isolating memory pages to support different OSes:Linux - typical support for
mlock
and zeroing, but also thinkingMFD_SECRET_*
, as posed here to further isolate sensitive memory from kernel space and even cache. Have not seen a merge upstream to a new revision yet, but interesting to think about.macOS -
mlock
again, but also potentially pushing support for Secure Enclave storage, which will requiring signing rather than our current symmetric encryption.Windows -
CryptProtectMemory
andSecureZeroMemory
for explicit zeroing.Backing to other native "keyring" implementations (Credential Manager, macOS Keychain) are also interesting and provides security and isolation for free(-ish).
The text was updated successfully, but these errors were encountered: