linux-ext4 - Proposal: A new 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: <20190110051500.GA32361@mit.edu>
Date:   Thu, 10 Jan 2019 00:15:00 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Dave Chinner <david@...morbit.com>,
        "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: A new fs-verity interface

The following approach is based in Darrick's suggestion:

int ioctl(fd, FS_IOC_ENABLE_VERITY, struct fsverity_arg *arg);

struct fsverity_arg {
       int fsv_donor_fd;
       u64 fsv_offset;
       u64 fsv_size;
};

fsv_offset and fsz_size must be a multiple of the file system block
size.  If the ioctl comples successfully, as a side effect the
donor_fd will have a hole punch operation on the specified range.  In
other words, the equivalent of operation of fallocate(fsv_donor_fd,
FALLOC_FL_PUNCH_HOLE, fsv_offset, fsv_size), and the file specified by
fd will be protected using fsverity.

It will be legal for fsv_donor_fd == fd, so this interface is a
superset of the original FS_IOC_ENABLE_VERITY ioctl.

This will hopefully make Christoph and Dave happy because the
interface does not presuppose how ext4 and f2fs will implement
fsverity behind the scenes.  However, it does not forbid it, and the
net cost is that ext4 and f2fs will have to implement code which
transplants the blocks from the donor_fd to fd in the case where
donor_fd != fd --- and in the case where blocks are encrypted using
fscrypt, we will have to decrypt the blocks from donor_fd and possibly
re-encrypt then in fd's per-file key, which means we'll have to add
extra complexity to implement the decrypt and re-encrypt passing
through the page cache.

But if this helps resolve Christoph and Dave's objections, it
shouldn't be _too_ much extra complexity.  Before we go ahead an
implement it, though, I'd appreciate a confirmation that this will
indeed actually resolve their complaints.

Thanks,

					- Ted