linux-kernel - Re: [Ecryptfs-devel] [PATCH] eCryptfs: fix possible fault in ecryptfs_sync

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:	Thu, 23 Aug 2007 10:52:11 -0400
From:	Erez Zadok <ezk@...sunysb.edu>
To:	Michael Halcrow <mhalcrow@...ibm.com>
Cc:	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>,
	moriai.satoshi@....ntt.co.jp, jsipek@...sunysb.edu,
	Andrew Morton <akpm@...ux-foundation.org>,
	ecryptfs-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [Ecryptfs-devel] [PATCH] eCryptfs: fix possible fault in ecryptfs_sync_page 

In message <20070823143745.GM22689@...crow.austin.ibm.com>, Michael Halcrow writes:
> On Thu, Aug 23, 2007 at 04:42:59PM +0900, Ryusuke Konishi wrote:
> > This will avoid a possible fault in ecryptfs_sync_page().
> 
> Acked-by: Michael Halcrow <mhalcrow@...ibm.com>
> 
> Note that there are other outstanding issues with eCryptfs on NFS. For
> instance, prepare_write()/commit_write() have gone away in -mm,
> leading to an oops when eCryptfs tries to call them directly, which is
> well deserved, since eCryptfs really should not be doing that. Unionfs
> has just two places where it calls vfs_read() and vfs_write()
> respectively; eCryptfs is a bit more complex, with multiple write
> paths that end up writing encrypted data and updating metadata in the
> header. I am currently trying to find a way to convert everything over
> to vfs_read() and vfs_write() in eCryptfs, in a way that does not
> ultimately result in a kernel hang.

Mike, check the latest unionfs 2.1.2 code in
http://unionfs.filesystems.org/.  In the past couple of months I've already
gotten rid of direct calls to prepare/commit_write in favor of
vfs_read/write.  There were a number of reasons for that mostly having to do
with races, deadlocks/hangs, and memory-pressure conditions.  I also have a
number of additional mmap related fixes in fs/unionfs/mmap.c that you should
probably look at as they're applicable to stacking in general.

Lastly, to stack on nfs, at the very least you'll probably need my lower_nd
fixes from unionfs as well, or something like it.  As of 2.6.23-rc3, you
need to stack on the nameidata structure even for nfs2/nfs3.  My patches
take care of that for now (until such a day as the VFS will have a true,
stackable, small intent structure that can be passed to a lower f/s).

Cheers,
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/