[PATCH] eccryptfs: select CONFIG_BUFFER_HEAD

[PATCH] eccryptfs: select CONFIG_BUFFER_HEAD

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

The ecryptfs file system uses functions from fs/buffer.c that
are only available when CONFIG_BUFFER_HEAD is enabled:

ld.lld-20: error: undefined symbol: block_dirty_folio
>>>               vmlinux.o:(ecryptfs_aops)
ld.lld-20: error: undefined symbol: block_invalidate_folio
>>>               vmlinux.o:(ecryptfs_aops)

When CONFIG_BLOCK is turned off completely, this is not needed,
so add a conditional 'select BUFFER_HEAD'.

Fixes: 7ba13abbd31e ("fs: Turn block_invalidatepage into block_invalidate_folio")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Ideally we would not depend on buffer heads and instead remove
the dependency here, but I could not immediately figure out how
to do that.
---
 fs/ecryptfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ecryptfs/Kconfig b/fs/ecryptfs/Kconfig
index 1bdeaa6d5790..b3c603c4f808 100644
--- a/fs/ecryptfs/Kconfig
+++ b/fs/ecryptfs/Kconfig
@@ -2,6 +2,7 @@
 config ECRYPT_FS
 	tristate "eCrypt filesystem layer support"
 	depends on KEYS && CRYPTO && (ENCRYPTED_KEYS || ENCRYPTED_KEYS=n)
+	select BUFFER_HEAD if BLOCK
 	select CRYPTO_ECB
 	select CRYPTO_CBC
 	select CRYPTO_MD5
-- 
2.39.5

ecryptfs is unmaintained and untested

[Matthew Wilcox]

On Mon, Oct 28, 2024 at 02:18:45PM +0000, Arnd Bergmann wrote:
> The ecryptfs file system uses functions from fs/buffer.c that
> are only available when CONFIG_BUFFER_HEAD is enabled:
> 
> ld.lld-20: error: undefined symbol: block_dirty_folio
> >>>               vmlinux.o:(ecryptfs_aops)
> ld.lld-20: error: undefined symbol: block_invalidate_folio
> >>>               vmlinux.o:(ecryptfs_aops)
> 
> When CONFIG_BLOCK is turned off completely, this is not needed,
> so add a conditional 'select BUFFER_HEAD'.

The comment says it doesn't work without CONFIG_BLOCK:

        /*
         * XXX: This is pretty broken for multiple reasons: ecryptfs does not
         * actually use buffer_heads, and ecryptfs will crash without
         * CONFIG_BLOCK.  But it matches the behavior before the default for
         * address_space_operations without the ->dirty_folio method was
         * cleaned up, so this is the best we can do without maintainer
         * feedback.

This comment has been there since June 2021, so I think we can just
delete ecryptfs now?

If we can't delete it for some reason, I think we can use
filemap_dirty_folio() and remove the setting of invalidate_folio()
as block_invalidate_folio() is a no-op if there are no folio_buffers.
ie this in lieu of your patch:

+++ b/fs/ecryptfs/mmap.c
@@ -514,17 +514,9 @@ static sector_t ecryptfs_bmap(struct address_space *mapping, sector_t block)
 
 const struct address_space_operations ecryptfs_aops = {
        /*
-        * XXX: This is pretty broken for multiple reasons: ecryptfs does not
-        * actually use buffer_heads, and ecryptfs will crash without
-        * CONFIG_BLOCK.  But it matches the behavior before the default for
-        * address_space_operations without the ->dirty_folio method was
-        * cleaned up, so this is the best we can do without maintainer
-        * feedback.
+        * XXX: This entire filesystem is unmaintained and untested.
         */
-#ifdef CONFIG_BLOCK
-       .dirty_folio    = block_dirty_folio,
-       .invalidate_folio = block_invalidate_folio,
-#endif
+       .dirty_folio = filemap_dirty_folio,
        .writepages = ecryptfs_writepages,
        .read_folio = ecryptfs_read_folio,
        .write_begin = ecryptfs_write_begin,

Re: ecryptfs is unmaintained and untested

[Arnd Bergmann]

On Mon, Oct 28, 2024, at 15:02, Matthew Wilcox wrote:
> On Mon, Oct 28, 2024 at 02:18:45PM +0000, Arnd Bergmann wrote:
>
> The comment says it doesn't work without CONFIG_BLOCK:
>
>         /*
>          * XXX: This is pretty broken for multiple reasons: ecryptfs does not
>          * actually use buffer_heads, and ecryptfs will crash without
>          * CONFIG_BLOCK.  But it matches the behavior before the default for
>          * address_space_operations without the ->dirty_folio method was
>          * cleaned up, so this is the best we can do without maintainer
>          * feedback.
>
> This comment has been there since June 2021, so I think we can just
> delete ecryptfs now?

I have no opinion on removing ecryptfs, but I don't how possibly
removing it is related to the patch I sent, as far as I can tell
it just means it relies on both CONFIG_BLOCK and CONFIG_BUFFER_HEAD
then.

Is there any indication that the last users that had files on
ecryptfs are unable to update their kernels?

> If we can't delete it for some reason, I think we can use
> filemap_dirty_folio() and remove the setting of invalidate_folio()
> as block_invalidate_folio() is a no-op if there are no folio_buffers.
> ie this in lieu of your patch:
>
> -#ifdef CONFIG_BLOCK
> -       .dirty_folio    = block_dirty_folio,
> -       .invalidate_folio = block_invalidate_folio,
> -#endif
> +       .dirty_folio = filemap_dirty_folio,
>         .writepages = ecryptfs_writepages,

This clearly addresses the build failure as well, so no objections
from me, but I don't understand what the functional difference is
here and would rely on you to write a changelog text for that change.

     Arnd

Re: ecryptfs is unmaintained and untested

[Theodore Ts'o]

On Mon, Oct 28, 2024 at 09:50:37PM +0000, Arnd Bergmann wrote:
> On Mon, Oct 28, 2024, at 15:02, Matthew Wilcox wrote:
> >
> > This comment has been there since June 2021, so I think we can just
> > delete ecryptfs now?
> 
> I have no opinion on removing ecryptfs, but I don't how possibly
> removing it is related to the patch I sent, as far as I can tell
> it just means it relies on both CONFIG_BLOCK and CONFIG_BUFFER_HEAD
> then.
> 
> Is there any indication that the last users that had files on
> ecryptfs are unable to update their kernels?

Debian is still shipping ecryptfs-utils and is building and including
the ecryptfs kernel module in their distro kernel.`

So it seems likely that there are probably a non-zero (although
probably relatively small) number of ecryptfs users out there.

	 	    	   	     	      - Ted

Re: ecryptfs is unmaintained and untested

[Tyler Hicks]

On 2024-10-28 21:33:28, Theodore Ts'o wrote:
> On Mon, Oct 28, 2024 at 09:50:37PM +0000, Arnd Bergmann wrote:
> > On Mon, Oct 28, 2024, at 15:02, Matthew Wilcox wrote:
> > >
> > > This comment has been there since June 2021, so I think we can just
> > > delete ecryptfs now?
> > 
> > I have no opinion on removing ecryptfs, but I don't how possibly
> > removing it is related to the patch I sent, as far as I can tell
> > it just means it relies on both CONFIG_BLOCK and CONFIG_BUFFER_HEAD
> > then.
> > 
> > Is there any indication that the last users that had files on
> > ecryptfs are unable to update their kernels?
> 
> Debian is still shipping ecryptfs-utils and is building and including
> the ecryptfs kernel module in their distro kernel.`
> 
> So it seems likely that there are probably a non-zero (although
> probably relatively small) number of ecryptfs users out there.

It would be good to discuss how we can get the message out to users to
migrate off of eCryptfs so that functionality can be reduced and
eventually it can be removed.

What do folks think about the following?

1. Print loud warnings at mount time that eCryptfs is deprecated and
   give a specific date when write support will be removed.
2. Remove write support at that date, while retaining read-only support
   to allow any lagging users to move their data to fscrypt or other
   alternatives.
3. Print loud warnings at mount that eCryptfs will be removed and give a
   specific date.
4. Remove it.

Suggestions on lead times for #2 and #4 would be appreciated.

Tyler

Re: ecryptfs is unmaintained and untested

[John Stultz]

On Mon, Oct 28, 2024 at 9:33 PM Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, Oct 28, 2024 at 09:50:37PM +0000, Arnd Bergmann wrote:
> > On Mon, Oct 28, 2024, at 15:02, Matthew Wilcox wrote:
> > >
> > > This comment has been there since June 2021, so I think we can just
> > > delete ecryptfs now?
> >
> > I have no opinion on removing ecryptfs, but I don't how possibly
> > removing it is related to the patch I sent, as far as I can tell
> > it just means it relies on both CONFIG_BLOCK and CONFIG_BUFFER_HEAD
> > then.
> >
> > Is there any indication that the last users that had files on
> > ecryptfs are unable to update their kernels?
>
> Debian is still shipping ecryptfs-utils and is building and including
> the ecryptfs kernel module in their distro kernel.`
>
> So it seems likely that there are probably a non-zero (although
> probably relatively small) number of ecryptfs users out there.

Yeah. Sadly I'm one, as I needed something to migrate off of when
encfs was deprecated.

Is there another soon-to-be-deprecated filesystem to encrypt
directories I should move to? :)

I definitely think we need some loud warnings and Tylers' suggestion
for a read-only grace period would be helpful.

thanks
-john

Re: ecryptfs is unmaintained and untested

[Theodore Ts'o]

On Mon, Oct 13, 2025 at 11:07:56PM -0700, John Stultz wrote:
> 
> Yeah. Sadly I'm one, as I needed something to migrate off of when
> encfs was deprecated.
> 
> Is there another soon-to-be-deprecated filesystem to encrypt
> directories I should move to? :)

Well, the closest way of encrypting directories is fscrypt.  The good
news is that it works on top of btrfs, ext4, f2fs, and ubifs, and it's
not likely to be deprecated given that it is used by chromeos and
android.  The bad news is that the integration with traditional Linux
desktop setups (e.g., login, etc.) was never completed.

This is probably because for many desktop and server configurations,
using dm-crypt is actually better suited and more secure.  It
certainly doesn't solve the "just encrypt a directory hierarchy in a
file system" and the "support multiple users' who might have different
encryption keys and which are mutually suspicious" use cases.  But
this appears to not be sufficiently interesting for distributions to
do that integration work.

					- Ted

Re: ecryptfs is unmaintained and untested

[John Stultz]

On Tue, Oct 14, 2025 at 7:39 AM Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, Oct 13, 2025 at 11:07:56PM -0700, John Stultz wrote:
> >
> > Yeah. Sadly I'm one, as I needed something to migrate off of when
> > encfs was deprecated.
> >
> > Is there another soon-to-be-deprecated filesystem to encrypt
> > directories I should move to? :)
>
> Well, the closest way of encrypting directories is fscrypt.  The good
> news is that it works on top of btrfs, ext4, f2fs, and ubifs, and it's
> not likely to be deprecated given that it is used by chromeos and
> android.  The bad news is that the integration with traditional Linux
> desktop setups (e.g., login, etc.) was never completed.

Yeah, though to my understanding fscrypt complicates backing up the
data in its encrypted form.
Having the fuse/overlay encryption approaches is nice because you can
just backup the underlying filesystem layer and ignore the overlay
mount.

> This is probably because for many desktop and server configurations,
> using dm-crypt is actually better suited and more secure.  It
> certainly doesn't solve the "just encrypt a directory hierarchy in a
> file system" and the "support multiple users' who might have different
> encryption keys and which are mutually suspicious" use cases.  But
> this appears to not be sufficiently interesting for distributions to
> do that integration work.

Mostly I avoid dm-crypt for personal files as I want the majority of
things (family pictures, etc) to be as simply recoverable as possible.
It's only for a small amount of things like email archives and
tax/financial documents that I'd like to have it be non-trivial to
access if my backup drive or desktop was stolen.

I've wondered if maybe something as simple as fuse mounting a password
protected zip file would do, but I'm guessing something a little more
modern like a fuse + age approach would be better. Unfortunately I'm
not finding anything so far.

thanks
-john

Re: ecryptfs is unmaintained and untested

[Martin Steigerwald]

Hi.

Theodore Ts'o - 14.10.25, 16:39:16 CEST:
> This is probably because for many desktop and server configurations,
> using dm-crypt is actually better suited and more secure.  It
> certainly doesn't solve the "just encrypt a directory hierarchy in a
> file system" and the "support multiple users' who might have different
> encryption keys and which are mutually suspicious" use cases.  But
> this appears to not be sufficiently interesting for distributions to
> do that integration work.

If it is just about encrypting a sub directory of the home directory there 
has been work to support that on Plasma desktop via Plasma Vault. It 
supports CryFS as default, EncFS (with a security warning about it) and 
gocryptfs. CryFS is interesting as it also obfuscates the directory 
hierarchy as well as object names. All of them are FUSE filesystems.

Maybe one of these – excluding EncFS – could be used for encrypting the 
complete home directory of a user. Preferably CryFS maybe. But I bet it 
will be quite a bit slower than ecryptfs¹. And I am not aware of any other 
desktop or distribution integration work regarding CryFS, gocryptfs or 
another alternative.

[1] "The increase in security when compared to other file systems comes at 
a performance cost. CryFS is fast enough to be used in practice. I'm 
getting a read speed to 170MB/s and a write speed of 80MB/s on my SSD 
machine, but other file systems are even faster."

https://www.cryfs.org/comparison

Best,
-- 
Martin

Re: ecryptfs is unmaintained and untested

[Martin Steigerwald]

John Stultz - 14.10.25, 18:38:52 CEST:
> Mostly I avoid dm-crypt for personal files as I want the majority of
> things (family pictures, etc) to be as simply recoverable as possible.
> It's only for a small amount of things like email archives and
> tax/financial documents that I'd like to have it be non-trivial to
> access if my backup drive or desktop was stolen.

See my hints about CryFS or gocryptfs in my other mail as used by Plasma 
Vault. I believe it might suit your use case quite well.

-- 
Martin

Re: ecryptfs is unmaintained and untested

[Theodore Ts'o]

On Tue, Oct 14, 2025 at 09:38:52AM -0700, John Stultz wrote:
> Yeah, though to my understanding fscrypt complicates backing up the
> data in its encrypted form.

Unfortunately, yes, that's correct.  Michael and I did throw around a
rough design for doing encrypted backups and saving the encrypted
per-file encryption key.  Actually doing the _backup_ wasn't that
difficult; but doing the *restore* was very tricky/painful.
Ultimately, we never implemented it because it wasn't necessarily for
the Android/ChromeOS use case, and because we weren't getting a lot of
interest for the desktop, without which having a better
general-purpose backup is lower priority.

> I've wondered if maybe something as simple as fuse mounting a password
> protected zip file would do, but I'm guessing something a little more
> modern like a fuse + age approach would be better. Unfortunately I'm
> not finding anything so far.

Darrick is doing a lot of work to significantly improve the
performance of fuse2fs.  So perhaps fuse mounting a dm-crypt device
backed by a loop device might be a possibility?

	       	    	 	      	   - Ted

Re: ecryptfs is unmaintained and untested

[Eric Biggers]

On Tue, Oct 14, 2025 at 10:39:16AM -0400, Theodore Ts'o wrote:
> On Mon, Oct 13, 2025 at 11:07:56PM -0700, John Stultz wrote:
> > 
> > Yeah. Sadly I'm one, as I needed something to migrate off of when
> > encfs was deprecated.
> > 
> > Is there another soon-to-be-deprecated filesystem to encrypt
> > directories I should move to? :)
> 
> Well, the closest way of encrypting directories is fscrypt.  The good
> news is that it works on top of btrfs, ext4, f2fs, and ubifs, and it's
> not likely to be deprecated given that it is used by chromeos and
> android.  The bad news is that the integration with traditional Linux
> desktop setups (e.g., login, etc.) was never completed.

The current set of filesystems that support fscrypt is ext4, f2fs,
ubifs, cephfs, and (out-of-tree) Lustre.  btrfs's support for fscrypt is
still under development, I'm afraid.  I'm told it's starting to be
worked on again.

While the main user of the fscrypt kernel feature is Android which has
its own userspace, there's also a userspace tool for general-purpose
Linux distros, also called fscrypt.  See
https://github.com/google/fscrypt and
https://wiki.archlinux.org/title/Fscrypt

I've been maintaining the 'fscrypt' userspace tool, and in the past I've
done quite a bit of work to improve it.  I also use it to encrypt the
home directory on my personal desktop.

It's true that it really could use some love, though.  It's not
something that I've been prioritizing recently, and no one else has
stepped up either.  (Compare to eCryptfs where Ubuntu adopted it, and
Canonical stepped up to develop and maintain ecryptfs-tools.  That's
just not something that's happened for fscrypt.)

There are other userspace programs that use the fscrypt kernel feature
too, such as systemd-homed and a new one called dirlock:
https://lwn.net/Articles/1038859/

- Eric

Re: ecryptfs is unmaintained and untested

[Theodore Ts'o]

On Tue, Oct 14, 2025 at 01:35:35PM -0700, Eric Biggers wrote:
> I've been maintaining the 'fscrypt' userspace tool, and in the past I've
> done quite a bit of work to improve it.  I also use it to encrypt the
> home directory on my personal desktop.

Do you have integration with PAM?  I assume you must if you are
encrypting your home directory, since there would need to have some
way to insert the key to unlock your home directory as part of
single-sign on.  Or are you only encrypting something like the Private
directory on your home directory, and entering the password separately
fromo the login password.

One of the really nice things of the ecryptfs integration, especialy
on Ubuntu (and I don't remember if Tyler was responsible for that
work; if so, kudos!) wasthat it was particularly eeamless.

	     	     	     	    - Ted

Re: ecryptfs is unmaintained and untested

[Eric Biggers]

On Tue, Oct 14, 2025 at 09:31:13PM -0400, Theodore Ts'o wrote:
> On Tue, Oct 14, 2025 at 01:35:35PM -0700, Eric Biggers wrote:
> > I've been maintaining the 'fscrypt' userspace tool, and in the past I've
> > done quite a bit of work to improve it.  I also use it to encrypt the
> > home directory on my personal desktop.
> 
> Do you have integration with PAM?  I assume you must if you are
> encrypting your home directory, since there would need to have some
> way to insert the key to unlock your home directory as part of
> single-sign on.  Or are you only encrypting something like the Private
> directory on your home directory, and entering the password separately
> fromo the login password.
> 
> One of the really nice things of the ecryptfs integration, especialy
> on Ubuntu (and I don't remember if Tyler was responsible for that
> work; if so, kudos!) wasthat it was particularly eeamless.

Yes, there's a PAM module called pam_fscrypt.

- Eric

Re: ecryptfs is unmaintained and untested

[René Herman]

> It would be good to discuss how we can get the message out to users to
> migrate off of eCryptfs so that functionality can be reduced and
> eventually it can be removed.
> 
> What do folks think about the following?
> 
> 1. Print loud warnings at mount time that eCryptfs is deprecated and
>    give a specific date when write support will be removed.
> 2. Remove write support at that date, while retaining read-only support
>    to allow any lagging users to move their data to fscrypt or other
>    alternatives.
> 3. Print loud warnings at mount that eCryptfs will be removed and give a
>    specific date.
> 4. Remove it.
> 
> Suggestions on lead times for #2 and #4 would be appreciated.

FWIW. Ever since Ubuntu dropped eCryptfs home-directory encryption 
already in I believe 18.04 from now 8 years ago, Linux Mint has probably 
been the single biggest consumer of eCryptfs: while based on Ubuntu, 
they've added back eCryptfs home-directory encryption in the installer 
ever since Ubuntu dropped it.

In the Mint project lead's latest blog he/they moreover proudly 
announced that their upcoming new & shiny GUI user-management tool will 
now support enabling home-directory also for at runtime added accounts 
(which up to now is done with adduser --encrypt-home from the command 
line only) rather than just the first, installer- created user account, 
and I am pretty much certain that the idea there still is *eCryptfs* 
home-directory-encryption. Mint is not the kind of project that 
routinely goes low-level.

https://blog.linuxmint.com/?p=4991

In any case then this is to say that they seem to not be planning on 
moving off of eCryptfs -- and Linux Mint is (probably?) the most popular 
Linux Distribution for/among new Linux users.

Have been commenting on this a bit as well on their forum, advocating 
for fully doing away with eCryptfs, but quite unsure that'll have any 
meaningful impact. Added the Mint project lead to the CC on this. If 
there's any progress to report on slashing eCryptfs he/they may want to 
be aware.

Regards,
Rene