Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates
 18.9.28.11 as permitted sender) receiver=protection.outlook.com;
 client-ip=18.9.28.11; helo=outgoing.mit.edu;
Date:   Tue, 12 Feb 2019 12:24:33 -0500
From:   "Theodore Y. Ts'o" <tytso@mit.edu>
To:     Mimi Zohar <zohar@linux.ibm.com>
CC:     Linus Torvalds <torvalds@linux-foundation.org>,
        Dave Chinner <david@fromorbit.com>,
        Christoph Hellwig <hch@infradead.org>,
        "Darrick J. Wong" <darrick.wong@oracle.com>,
        Eric Biggers <ebiggers@kernel.org>,
        <linux-fscrypt@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        <linux-ext4@vger.kernel.org>,
        <linux-f2fs-devel@lists.sourceforge.net>,
        James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: Re: Proposal: Yet another possible fs-verity interface
Message-ID: <20190212172433.GT23000@mit.edu>
References: <20190207031101.GA7387@mit.edu>
 <CAHk-=wh2j+Yy28H_QxEdsP=k9xcHxjCG1PqKAF2Uv=ckK8oPug@mail.gmail.com>
 <1549807615.12743.109.camel@linux.ibm.com>
 <20190212053123.GR23000@mit.edu>
 <1549976812.12743.225.camel@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1549976812.12743.225.camel@linux.ibm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2019 17:24:36.9420
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c25df7a8-6dea-432e-bf45-08d6910ef6ab
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b;Ip=[18.9.28.11];Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1SPR00MB23
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-ext4.vger.kernel.org>
X-Mailing-List: linux-ext4@vger.kernel.org

On Tue, Feb 12, 2019 at 08:06:52AM -0500, Mimi Zohar wrote:
> Yes, I understand that your primary goal hasn't changed.??Linus was
> suggesting "the interface be made idempotent" to support "filesystems
> that don't actually have any long-term storage model for the merkle
> tree. ?IOW, you could do the merkle tree calculation (and
> verification) every time at bootup". ?In that context, I asked whether
> the Merkle tree file hash would be for every file on the filesystem or
> not, and how to identify those files.

I have no idea; *we're* certainly never going to use it in that mode.
Until we have a use case, answering your questions about when the
Merkle tree hash would be calculated, etc. is not something I can do.

If IMA wants to use it in that way, let's talk, and we probably can
drop everyone off the cc line.  But there's a limit to much work the
open source community can expect to extort out of people who are
trying to get a feature upstream.  If it's very closely related, and
it's a small amount of work, that's a no-brainer.  But past a certain
point, it's a completely new feature, and it stops being fair....

> > > The existing file hashes included in the measurement list and the
> > > audit log, are currently being used for remote attestation, forensics
> > > and security analytics.
> 
> Again, the context for this comment was Linus' suggestion "each level
> of the merkle tree needs to have a hash seeding thing or whatever."
> Up to this point, I had assumed the Merkle tree file root hash could
> be used as an identifier, similar to the file hash.??With his
> suggestion, it sounds like the Merkle tree file root hash would be
> system dependent, making it useless for the above usages.

Yeah, I have no idea what Linus was talking about there.  The only
thing that really makes sense is that if you don't have any
file-system place to store a seed, you don't use a seed for the Merkle
tree, and for a given set of bytes, the Merkle root hash is the same.
So it's basically an expensive to calculate crypto checksum, as I said.

If that's helpful to IMA, we need a crisp set of requirements and
expectations of how IMA would use it.  And this includes, as I
mentioned in my other e-mail, questions like how long do we keep the
Merkle tree pinned in memory, how it would be used (I assume it would
be something called from IMA's measurement hook, but maybe you have
other ideas).  Bottom line --- I need *you* to answer the questions
that you posed.  :-)

Once we get the requirements, we can figure out how we can architect
something sane --- but adding this extra feature is going to be a lot
work, make no mistake about it.  One of the other things we will need
to figure out is how to hook into other file systems's readpages
model.  There's no standardization here, since file systems don't even
have to use the page cache!

So my strong preference would be to get the base fs-verity feature in,
and then we can look into how it would be extended for this new,
completely different use case.  And hopefully, the people who would
benefit from this new use case, would be willing to contribute some of
the engineering effort to make it happen?  :-)

					- Ted