linux-kernel - Re: ecryptfs is unmaintained and untested

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <ef98d985-6153-416d-9d5e-9a8a8595461a@app.fastmail.com>
Date: Mon, 28 Oct 2024 21:50:37 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Matthew Wilcox" <willy@...radead.org>, "Arnd Bergmann" <arnd@...nel.org>
Cc: "Tyler Hicks" <code@...icks.com>,
 "Damien Le Moal" <damien.lemoal@...nsource.wdc.com>,
 ecryptfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ecryptfs is unmaintained and untested

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