linux-ext4 - Proposal: Yet another possible fs-verity interface

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-next>] [day] [month] [year] [list]

Message-ID: <20190207031101.GA7387@mit.edu>
Date:   Wed, 6 Feb 2019 22:11:01 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
CC:     Dave Chinner <david@...morbit.com>,
        Christoph Hellwig <hch@...radead.org>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Eric Biggers <ebiggers@...nel.org>,
        <linux-fscrypt@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        <linux-ext4@...r.kernel.org>,
        <linux-f2fs-devel@...ts.sourceforge.net>
Subject: Proposal: Yet another possible fs-verity interface

After doing a lot of thinking and conferring with the other fs-verity
developers, our current thinking is to simply move the Merkle tree
creation into the kernel.  The upside of doing this is it completely
bypasses all of the complaints about how to transfer the Merkle tree
from userspace to the kernel.  It avoids the complexities of
redesigning the xattr interface, or creating a magic fd which could be
lseek'ed, mmap'ed, read, written, etc. to transfer the Merkle tree,
etc.  Calculating the Merkle tree from a code complexity is going to
be simpler.

The downside of this approach is that it can take a lot of CPU time in
the kernel (it would have to do be done in a kernel thread).  An extra
bit of complication is worrying about how to handle the situation
where if the kernel crashes.  The current thinking is that the ioctl
which enable fs-verity protection on the file will make sure that the
file descriptor is not otherwise opened for writing, and then set the
immutable bit.  Once the Merkle tree is written and finalized, the
fs-verity flag would be set and the immutable bit would be cleared.
The exact mechanisms of crash recovery would be file-system dependent,
and TBD, but would probably rely on the journalling mechanisms
available (e.g., ext4 might rely on the orphan list; f2fs might use
copy-on-write semantics; etc.)

This effectively moves the complexity from the interface (which is
where we seem to be getting hung up) to the implementation, but as
stated above, the actual code to create a Merkle tree is fairly simple.

Hopefully this will cut through the current complaints of the
fs-verity API.

Cheers,

					- Ted