kernel/linux.git/fs/ecryptfs/ecryptfs_kernel.h, branch v6.19.11

ecryptfs: Use MD5 library instead of crypto_shash

2025-10-31T09:12:35+00:00

eCryptfs uses MD5 for a couple unusual purposes: to "mix" the key into the IVs for file contents encryption (similar to ESSIV), and to prepend some key-dependent bytes to the plaintext when encrypting filenames (which is useless since eCryptfs encrypts the filenames with ECB). Currently, eCryptfs computes these MD5 hashes using the crypto_shash API. Update it to instead use the MD5 library API. This is simpler and faster: the library doesn't require memory allocations, can't fail, and provides direct access to MD5 without overhead such as indirect calls. To preserve the existing behavior of eCryptfs support being disabled when the kernel is booted with "fips=1", make ecryptfs_get_tree() check fips_enabled itself. Previously it relied on crypto_alloc_shash("md5") failing. I don't know for sure that this is actually needed; e.g., it could be argued that eCryptfs's use of MD5 isn't for a security purpose as far as FIPS is concerned. But this preserves the existing behavior. Tested by verifying that an existing eCryptfs can still be mounted with a kernel that has this commit, with all the files matching. Also tested creating a filesystem with this commit and mounting+reading it without. Signed-off-by: Eric Biggers Link: https://patch.msgid.link/20251011200010.193140-1-ebiggers@kernel.org Acked-by: Ard Biesheuvel Signed-off-by: Christian Brauner

ecryptfs: get rid of pointless mount references in ecryptfs dentries

2025-09-16T01:26:44+00:00

->lower_path.mnt has the same value for all dentries on given ecryptfs instance and if somebody goes for mountpoint-crossing variant where that would not be true, we can deal with that when it happens (and _not_ with duplicating these reference into each dentry). As it is, we are better off just sticking a reference into ecryptfs-private part of superblock and keeping it pinned until ->kill_sb(). That way we can stick a reference to underlying dentry right into ->d_fsdata of ecryptfs one, getting rid of indirection through struct ecryptfs_dentry_info, along with the entire struct ecryptfs_dentry_info machinery. [kudos to Dan Carpenter for spotting a bug in ecryptfs_get_tree() part] Reviewed-by: Christian Brauner Signed-off-by: Al Viro

ecryptfs: Convert ecryptfs_decrypt_page() to take a folio

2024-11-05T16:20:00+00:00

Both callers have a folio, so pass it in and use it throughout. Signed-off-by: Matthew Wilcox (Oracle) Link: https://lore.kernel.org/r/20241025190822.1319162-9-willy@infradead.org Signed-off-by: Christian Brauner

ecryptfs: Convert ecryptfs_encrypt_page() to take a folio

2024-11-05T16:19:59+00:00

All three callers have a folio, so pass it in and use it throughout. Signed-off-by: Matthew Wilcox (Oracle) Link: https://lore.kernel.org/r/20241025190822.1319162-8-willy@infradead.org Signed-off-by: Christian Brauner

ecryptfs: Convert ecryptfs_write_lower_page_segment() to take a folio

2024-11-05T16:19:59+00:00

Both callers now have a folio, so pass it in and use it throughout. Signed-off-by: Matthew Wilcox (Oracle) Link: https://lore.kernel.org/r/20241025190822.1319162-7-willy@infradead.org Signed-off-by: Christian Brauner

ecryptfs: Convert ecryptfs_write() to use a folio

2024-11-05T16:19:59+00:00

Remove ecryptfs_get_locked_page() and call read_mapping_folio() directly. Use the folio throught this function. Signed-off-by: Matthew Wilcox (Oracle) Link: https://lore.kernel.org/r/20241025190822.1319162-6-willy@infradead.org Reviewed-by: Pankaj Raghav Signed-off-by: Christian Brauner

ecryptfs: Convert ecryptfs_read_lower_page_segment() to take a folio

2024-11-05T16:19:59+00:00

All callers have a folio, so pass it in and use it directly. This will not work for large folios, but I doubt anybody wants to use large folios with ecryptfs. Signed-off-by: Matthew Wilcox (Oracle) Link: https://lore.kernel.org/r/20241025190822.1319162-5-willy@infradead.org Signed-off-by: Christian Brauner

ecryptfs: move ecryptfs_xattr_handlers to .rodata

2023-10-09T14:24:17+00:00

This makes it harder for accidental or malicious changes to ecryptfs_xattr_handlers at runtime. Cc: Tyler Hicks Cc: ecryptfs@vger.kernel.org Signed-off-by: Wedson Almeida Filho Link: https://lore.kernel.org/r/20230930050033.41174-8-wedsonaf@gmail.com Signed-off-by: Christian Brauner

ecryptfs: constify path

2022-09-01T21:40:38+00:00

Reviewed-by: Christian Brauner (Microsoft) Signed-off-by: Al Viro

Merge tag 'ecryptfs-5.13-rc1-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs

2021-05-06T17:06:39+00:00

Pull ecryptfs updates from Tyler Hicks: "Code cleanups and a bug fix - W=1 compiler warning cleanups - Mutex initialization simplification - Protect against NULL pointer exception during mount" * tag 'ecryptfs-5.13-rc1-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs: ecryptfs: fix kernel panic with null dev_name ecryptfs: remove unused helpers ecryptfs: Fix typo in message eCryptfs: Use DEFINE_MUTEX() for mutex lock ecryptfs: keystore: Fix some kernel-doc issues and demote non-conformant headers ecryptfs: inode: Help out nearly-there header and demote non-conformant ones ecryptfs: mmap: Help out one function header and demote other abuses ecryptfs: crypto: Supply some missing param descriptions and demote abuses ecryptfs: miscdev: File headers are not good kernel-doc candidates ecryptfs: main: Demote a bunch of non-conformant kernel-doc headers ecryptfs: messaging: Add missing param descriptions and demote abuses ecryptfs: super: Fix formatting, naming and kernel-doc abuses ecryptfs: file: Demote kernel-doc abuses ecryptfs: kthread: Demote file header and provide description for 'cred' ecryptfs: dentry: File headers are not good candidates for kernel-doc ecryptfs: debug: Demote a couple of kernel-doc abuses ecryptfs: read_write: File headers do not make good candidates for kernel-doc ecryptfs: use DEFINE_MUTEX() for mutex lock eCryptfs: add a semicolon