linux-ext4 - Re: Consolidated file encryption interface/semantics?

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: <20160111233620.GB6033@dastard>
Date:	Tue, 12 Jan 2016 10:36:20 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Richard Weinberger <richard@....at>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-f2fs-devel@...ts.sourceforge.net, linux-ext4@...r.kernel.org
Subject: Re: Consolidated file encryption interface/semantics?

On Mon, Jan 11, 2016 at 11:56:25PM +0100, Richard Weinberger wrote:
> Hi!
> 
> I consider adding file encryption to UBIFS.
> While looking into ext4 and f2fs I realized that both
> use the same data structures/concepts.

When the ext4 code was first posted, I noted that 90% of the
implementation was not ext4 specific at all. I asked that the
encryption part of it be lifted to fs/ and the API made generic so
that it can be shared without needing to copy and re-review
encryption code (which is notoriously hard to get right) when others
implement the same fucntionality. This was considered SEP.

> f2fs copy&pasted a lot from ext4.

Yes, they did, even though I asked them not to, but to instead pull
all the code that is non-ext4 specific up to the VFS first and then
use that. Again, this was considered SEP.

> Before I do the next copy&paste, I'd to ask whether it would make sense
> to more parts of the ioctl() interface out to VFS?

Yes, unfortunately you're the first "somebody else" who is going to
have to deal with this problem. It's not just the API - most of the
encryption implementation is also copy and pasted, too.

This simply hasn't got to the top of my list of stuff to do for XFS
yet, so I haven't started down this path yet. However, if you do
start on the hard work  to pull all this stuff up into the VFS and
generic helpers, I'll do what I can to get the necessary parts of
XFS working with it as well....

[snip]

> So, the data structures are identical and AFAIK also the supported cipher modes are.
> But as both use their own ioctls having a single tool to control file encryption
> can be error prone in future.
> Interestingly the current ioctls for ext4 and f2fs resolve to the same integers,
> is this on purpose? :)

Yes, so that when someone factors it all into a generic
implementation the new "FS_IOC*" ioctl API will be binary compatible
with the existing ext4 and f2fs ioctl implementations and the
existing userspace tools will just continue to work.

> Wouldn't it be worthwhile having exactly the same ioctls such that util-linux could offer
> a decent file encryption tool which can be used by all file systems with file encryption
> support?

Yes, it should have been done that way in the first place.

> Another thing are semantics, ext4 implemented a policy which controls
> under which conditions encrypted files are allowed to be unlinked, moved, etc...
> f2fs adopted these from ext4. But can't we do that in VFS or at least
> agree one a policy and document it? :-)

Yes, we should. Having a single set of policies implemented and
enforced at the VFS is how this should be done. Users will
absolutely hate us if per-file encryption devolves into APIs and
policies that differ between filesystems.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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