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  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]
Date:   Mon, 18 Apr 2022 15:27:16 -0700
From:   Eric Biggers <>
To:     常凤楠 <>
Cc:     "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
Subject: Re: [PATCH 2/3] f2fs: notify when device not supprt inlinecrypt

On Mon, Apr 18, 2022 at 07:34:52AM +0000, 常凤楠 wrote:
> > -----Original Message-----
> > From: Eric Biggers <>
> > Sent: Monday, April 18, 2022 3:22 PM
> > To: 常凤楠 <>
> > Cc:;;;
> >;;;
> >;
> > Subject: Re: [PATCH 2/3] f2fs: notify when device not supprt inlinecrypt
> > 
> > On Mon, Apr 18, 2022 at 02:33:11PM +0800, Fengnan Chang via
> > Linux-f2fs-devel wrote:
> > > Notify when mount filesystem with -o inlinecrypt option, but the
> > > device not support inlinecrypt.
> > >
> > > Signed-off-by: Fengnan Chang <>
> > 
> > You didn't include a cover letter in this patchset.  Can you explain what
> > problem this patchset is meant to solve?
> What I'm try to make is when devices not support inlinecrypt, do not show inlinecrypt in mount option. 
> When I test fscrypt first, it make me confused. Not a real problem, just make this logical more reasonable.
> Do you think this needs to be revised?

Well, I'm just not sure we should do this, or at least by itself, given that
support for inline encryption is not an either-or thing, and the inlinecrypt
mount option is already documented to apply only to files where inline
encryption can be used.  See Documentation/filesystems/fscrypt.rst:

	Note that the "inlinecrypt" mount option just specifies to use inline
	encryption when possible; it doesn't force its use.  fscrypt will
	still fall back to using the kernel crypto API on files where the
	inline encryption hardware doesn't have the needed crypto capabilities
	(e.g. support for the needed encryption algorithm and data unit size)
	and where blk-crypto-fallback is unusable.  (For blk-crypto-fallback
	to be usable, it must be enabled in the kernel configuration with

And Documentation/admin-guide/ext4.rst and Documentation/filesystems/f2fs.rst:

	When possible, encrypt/decrypt the contents of encrypted files using the
	blk-crypto framework rather than filesystem-layer encryption. ...

If we do want to warn when inlinecrypt is given but inline encryption cannot be
used, your patchset isn't enough since it only covers the case where no form of
inline encryption is available at all, and not the case where some form of
inline encryption is available but the filesystem can't use it.

- Eric

Powered by blists - more mailing lists