fscrypt: mention init_on_free instead of page poisoning

Commit Message

Eric Biggers March 4, 2025, 9:01 p.m. UTC

From: Eric Biggers <[e-mail]>

Page poisoning is an older debug option.  The modern way to initialize
memory on free for security reasons is to set init_on_free=1.

Signed-off-by: Eric Biggers <[e-mail]>
---
 Documentation/filesystems/fscrypt.rst | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)


base-commit: eea957d8db1d1764c9c4b3c7fc5c86dbccb71fdc

Patch

diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
index 004f7fa48a469..e803299085492 100644
--- a/Documentation/filesystems/fscrypt.rst
+++ b/Documentation/filesystems/fscrypt.rst
@@ -135,13 +135,12 @@  However, these ioctls have some limitations:
   containing keys to prevent it from being swapped out.
 
 - In general, decrypted contents and filenames in the kernel VFS
   caches are freed but not wiped.  Therefore, portions thereof may be
   recoverable from freed memory, even after the corresponding key(s)
-  were wiped.  To partially solve this, you can set
-  CONFIG_PAGE_POISONING=y in your kernel config and add page_poison=1
-  to your kernel command line.  However, this has a performance cost.
+  were wiped.  To partially solve this, you can add init_on_free=1 to
+  your kernel command line.  However, this has a performance cost.
 
 - Secret keys might still exist in CPU registers, in crypto
   accelerator hardware (if used by the crypto API to implement any of
   the algorithms), or in other places not explicitly considered here.