All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Baoquan He <baoquan.he@linux.dev>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
	linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org,
	Kemeng Shi <shikemeng@huaweicloud.com>,
	Nhat Pham <nphamcs@gmail.com>, Barry Song <baohua@kernel.org>,
	Youngjun Park <youngjun.park@lge.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] mm/swap: reject swapon() on filesystem-level encrypted files
Date: Fri, 31 Jul 2026 11:14:08 -0700	[thread overview]
Message-ID: <20260731181408.GA12803@sol> (raw)
In-Reply-To: <amy7Biucbf-et5O2@MiWiFi-R3L-srv>

On Fri, Jul 31, 2026 at 11:11:02PM +0800, Baoquan He wrote:
> On 07/30/26 at 11:48am, Eric Biggers wrote:
> > ext4 and f2fs don't prevent filesystem-level encrypted files from being
> > set up directly as swap files.  In this case, encryption is bypassed.
> > 
> > No one should be doing this, vs. the methods of encrypted swap that
> > actually do work (such as swapping to a dm-crypt device, or swapping to
> > a loopback device on top of a filesystem-level encrypted file).
> > 
> > Nevertheless, to prevent user error, make swapon() explicitly reject
> > this case.  Document this behavior in fscrypt.rst as well.
> > 
> > Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
> > Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > ---
> >  Documentation/filesystems/fscrypt.rst | 4 ++++
> >  mm/swapfile.c                         | 4 ++++
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
> > index c0dd35f1af12..cba1989777da 100644
> > --- a/Documentation/filesystems/fscrypt.rst
> > +++ b/Documentation/filesystems/fscrypt.rst
> > @@ -1238,6 +1238,10 @@ astute users may notice some differences in behavior:
> >  
> >  - DAX (Direct Access) is not supported on encrypted files.
> >  
> > +- Encrypted files cannot be used directly as swap files.  To swap to
> > +  an encrypted file, set up a loopback device on top of it.
> > +  Alternatively, encrypted swap can use a dm-crypt device instead.
> > +
> >  - The maximum length of an encrypted symlink is 2 bytes shorter than
> >    the maximum length of an unencrypted symlink.  For example, on an
> >    EXT4 filesystem with a 4K block size, unencrypted symlinks can be up
> > diff --git a/mm/swapfile.c b/mm/swapfile.c
> > index 78b49b0658ad..e4991da81b5f 100644
> > --- a/mm/swapfile.c
> > +++ b/mm/swapfile.c
> > @@ -3650,6 +3650,10 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
> >  		error = -EBUSY;
> >  		goto bad_swap_unlock_inode;
> >  	}
> > +	if (IS_ENCRYPTED(inode)) {
> > +		error = -EINVAL;
> > +		goto bad_swap_unlock_inode;
> > +	}
> 
> Sounds reasonable to me.
> 
> One minor suggestion: it might be helpful to emit a pr_warn_once()
> explaining *why* the swapon was rejected and pointing users to the
> dm-crypt / loopback alternatives, so the -EINVAL isn't opaque.
> Optional though -- the check itself is what matters.

How's this?

    pr_warn_once("Filesystem-level encrypted swapfile '%s' is unsupported. Create a loop device over it, or use dm-crypt\n", name->name);

> And this patch updates fscrypt.rst. Would it be good to also
> update the swapon(8) man page to document the new -EINVAL
> condition?
> 
> Other than these,
> 
> Reviewed-by: Baoquan He <baoquan.he@linux.dev>

swapon(8) is for the util-linux program, not the syscall, so it doesn't
document error codes specifically.  It does have a NOTES section that
incompletely documents filesystem-specific constraints on swap files.
It's missing most of the current constraints.  But sure, I'll send a
patch that adds a note to there about this one.  That will be a
util-linux patch.

- Eric


WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Baoquan He <baoquan.he@linux.dev>
Cc: Barry Song <baohua@kernel.org>, Kairui Song <kasong@tencent.com>,
	Nhat Pham <nphamcs@gmail.com>, Chris Li <chrisl@kernel.org>,
	Youngjun Park <youngjun.park@lge.com>,
	Kemeng Shi <shikemeng@huaweicloud.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, linux-mm@kvack.org,
	linux-fscrypt@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH] mm/swap: reject swapon() on filesystem-level encrypted files
Date: Fri, 31 Jul 2026 11:14:08 -0700	[thread overview]
Message-ID: <20260731181408.GA12803@sol> (raw)
In-Reply-To: <amy7Biucbf-et5O2@MiWiFi-R3L-srv>

On Fri, Jul 31, 2026 at 11:11:02PM +0800, Baoquan He wrote:
> On 07/30/26 at 11:48am, Eric Biggers wrote:
> > ext4 and f2fs don't prevent filesystem-level encrypted files from being
> > set up directly as swap files.  In this case, encryption is bypassed.
> > 
> > No one should be doing this, vs. the methods of encrypted swap that
> > actually do work (such as swapping to a dm-crypt device, or swapping to
> > a loopback device on top of a filesystem-level encrypted file).
> > 
> > Nevertheless, to prevent user error, make swapon() explicitly reject
> > this case.  Document this behavior in fscrypt.rst as well.
> > 
> > Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
> > Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > ---
> >  Documentation/filesystems/fscrypt.rst | 4 ++++
> >  mm/swapfile.c                         | 4 ++++
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
> > index c0dd35f1af12..cba1989777da 100644
> > --- a/Documentation/filesystems/fscrypt.rst
> > +++ b/Documentation/filesystems/fscrypt.rst
> > @@ -1238,6 +1238,10 @@ astute users may notice some differences in behavior:
> >  
> >  - DAX (Direct Access) is not supported on encrypted files.
> >  
> > +- Encrypted files cannot be used directly as swap files.  To swap to
> > +  an encrypted file, set up a loopback device on top of it.
> > +  Alternatively, encrypted swap can use a dm-crypt device instead.
> > +
> >  - The maximum length of an encrypted symlink is 2 bytes shorter than
> >    the maximum length of an unencrypted symlink.  For example, on an
> >    EXT4 filesystem with a 4K block size, unencrypted symlinks can be up
> > diff --git a/mm/swapfile.c b/mm/swapfile.c
> > index 78b49b0658ad..e4991da81b5f 100644
> > --- a/mm/swapfile.c
> > +++ b/mm/swapfile.c
> > @@ -3650,6 +3650,10 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
> >  		error = -EBUSY;
> >  		goto bad_swap_unlock_inode;
> >  	}
> > +	if (IS_ENCRYPTED(inode)) {
> > +		error = -EINVAL;
> > +		goto bad_swap_unlock_inode;
> > +	}
> 
> Sounds reasonable to me.
> 
> One minor suggestion: it might be helpful to emit a pr_warn_once()
> explaining *why* the swapon was rejected and pointing users to the
> dm-crypt / loopback alternatives, so the -EINVAL isn't opaque.
> Optional though -- the check itself is what matters.

How's this?

    pr_warn_once("Filesystem-level encrypted swapfile '%s' is unsupported. Create a loop device over it, or use dm-crypt\n", name->name);

> And this patch updates fscrypt.rst. Would it be good to also
> update the swapon(8) man page to document the new -EINVAL
> condition?
> 
> Other than these,
> 
> Reviewed-by: Baoquan He <baoquan.he@linux.dev>

swapon(8) is for the util-linux program, not the syscall, so it doesn't
document error codes specifically.  It does have a NOTES section that
incompletely documents filesystem-specific constraints on swap files.
It's missing most of the current constraints.  But sure, I'll send a
patch that adds a note to there about this one.  That will be a
util-linux patch.

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2026-07-31 18:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 18:48 [PATCH] mm/swap: reject swapon() on filesystem-level encrypted files Eric Biggers
2026-07-30 18:48 ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-07-30 19:53 ` Andrew Morton
2026-07-30 19:53   ` [f2fs-dev] " Andrew Morton
2026-07-30 20:30   ` Eric Biggers
2026-07-30 20:30     ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-07-31  3:49     ` Darrick J. Wong
2026-07-31  3:49       ` [f2fs-dev] " Darrick J. Wong via Linux-f2fs-devel
2026-07-31  4:04       ` Eric Biggers
2026-07-31  4:04         ` [f2fs-dev] " Eric Biggers via Linux-f2fs-devel
2026-07-31 15:11 ` Baoquan He
2026-07-31 15:11   ` [f2fs-dev] " Baoquan He
2026-07-31 18:14   ` Eric Biggers [this message]
2026-07-31 18:14     ` Eric Biggers via Linux-f2fs-devel
2026-08-01  0:46     ` Baoquan He
2026-08-01  0:46       ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260731181408.GA12803@sol \
    --to=ebiggers@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baoquan.he@linux.dev \
    --cc=chrisl@kernel.org \
    --cc=kasong@tencent.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=shikemeng@huaweicloud.com \
    --cc=stable@vger.kernel.org \
    --cc=youngjun.park@lge.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.