linux-ext4 - Re: 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190212171109.GS23000@mit.edu>
Date:   Tue, 12 Feb 2019 12:11:09 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Mimi Zohar <zohar@...ux.ibm.com>
CC:     Linus Torvalds <torvalds@...ux-foundation.org>,
        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: Re: Proposal: Yet another possible fs-verity interface

On Tue, Feb 12, 2019 at 09:44:39AM -0500, Mimi Zohar wrote:
> Ted, one of the problems with IMA is that the file hash/signature
> verification is at file open.  It isn't aware when files are brought
> in from cache.  Does fs-verity re-verify blocks as they're restored
> from cache?  For some use cases, that might justify the up front cost
> associated with building the Merkle tree.

fs-verity as designed and implemented today *only* verifies blocks as
they are read from the file system.  The Merkle tree is stored on
disk, and we don't verify all of the pages at open time.  That's the
whole *point* of fs-verity.  So when you say re-verify, that's simply
not correct.

Could we change it so that there is an optional mode where Merkle tree
is kept pinned in memory and recalculated the first time the file is
opened?  I suppose; the overhead is "only" 0.8% of the file size.  But
for big files, it adds up; and if you never use most of the file (say,
it's an unstripped executable with debugging information), you end up
paying twice --- once to calculate the Merkle tree (in CPU and Disk
time wasted), and a second time by pinning the full Merkle tree in
memory.  Also, it leaves open the question of how aggressively we drop
the Merkle tree once the file is closed.  Do we wait until the inode
gets purged from the inode cache?  That might pin the memory for way
too long.  Do we drop the Merkle tree the moment the inode's open
count goes to zero?

If it's not too hard to add, and if we're generating the Merkle tree
in the kernel, it's something we could do, I suppose.  But it's not
something *we're* going to use, so I'm not terribly excited about
wasting effort on work that just bitrots if no one is actually going
to use it in that way.

If you are willing to commit that IMA will use it in that way, and
you're fairly sure IMA users are going to be willing to pay the memory
tax, we can look into adding it, if it's doesn't add too much effort
on our part.  I just want to be clear that this is a "yes, we would
definitely use such a thing", as opposed to, "it might be nice...."

Cheers,

					- Ted