linux-ext4 - Re: [PATCH] ext4 crypto: migrate into vfs's crypto engine

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]

Date:	Wed, 4 May 2016 21:22:48 -0700
From:	Jaegeuk Kim <jaegeuk@...nel.org>
To:	Theodore Ts'o <tytso@....edu>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4 crypto: migrate into vfs's crypto engine

On Wed, May 04, 2016 at 11:20:22PM -0400, Theodore Ts'o wrote:
> On Mon, Apr 25, 2016 at 05:15:36PM -0700, Jaegeuk Kim wrote:
> > This patch removes the most parts of internal crypto codes.
> > And then, it modifies and adds some ext4-specific crypt codes to use the generic
> > facility.
> > 
> > Signed-off-by: Jaegeuk Kim <jaegeuk@...nel.org>
> 
> So I just tried this patch, and one big problem with it is that it
> breaks backwards compatibility with existing userspace code, which
> assumes that the name of the keys are prefixed with "ext4:".  I see
> that in fs/crypto.h you've changed it to be "fscrypto:".  Which is
> more general, perhaps, but the problem is that it's not what the
> existing shipping code (for example, in the Android N preview release)
> and what e2fsprogs's e4crypto is using.

I also worried about that before, but I thought there was no shipped
fs_encryption-enabled product.
Actually, f2fs has the same issue as well, since "f2fs:" was used before. :(

> If we want to use fscrypto: as a more general prefix, I could see
> doing that, but we need to provide for backwards compatibility ---
> which means that at least for ext4, we will need to look for keys
> using both the new and old prefix, and we would also want change
> e4crypto to set keys with both the "ext4" and the more general
> "fscrypto" prefix.

Got it. Let me add (*key_prefix(inode)) in fscrypt_operations so that filesystem
can give a specific prefix additionally.
Once fscrypto supports both of prefixes, does e4crypto have to set "fscrypto"?
The "ext4" should work all the time tho.

Thanks,

> 
> Cheers,
> 
> 					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html