From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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>
Subject: Re: Proposal: A new fs-verity interface
Date: Tue, 29 Jan 2019 10:48:39 -0500 [thread overview]
Message-ID: <20190129154839.GA4421@mit.edu> (raw)
In-Reply-To: <CAHk-=wjw+tAKu7fM3GwUX9i7LBFuvB=ohqXj+KgQQaW3pCzfxg@mail.gmail.com>
On Fri, Jan 25, 2019 at 01:35:05PM +1300, Linus Torvalds wrote:
> But that's the whole hiding thing. Why do you feel you need to do
> that? Why not just leave it alone, and leave it visible, and say "hey,
> the merkle data for file X comes from here".
There are a number of downsides:
*) It's ugly that files that have to live somewhere (e.g., a dot file,
some other directory, etc.) in the directory hierarchy, when theyt
are fundamentally part of the file that is being protected --- that
is, it is file metadata.
*) We don't want to allow the files to be deted, since it breaks the
protection; that either has to make the original file useful, since
the security policy is we can't trust the file --- which might be a
privileged APK (think setuid binary), or we have to make the file
immutable and it from being deleted.
*) When we delete the original file, userspace now has to manually
clean up the Merkle data for the file.
So keeping it hidden is just cleaner.
You're right that making the Merkle data explicit available in some
form (either via an xattr or a separate file) would make it easier to
copy the file, but that's not something that is needed in practice.
So it's an advantage, but it wasn't one that we had considered
important. For example for most executables on a desktop, they are
installed via a package manager, and they are deleted when the package
is updated. Or in the case of an Android APK, copying it is not
something that is done once it is downloaded to the device.
> In fact, if you want to have merkle data for small files (where the
> merkle data itself is just a few words), then having it in a separate
> file and as part of the inode inline data doesn't seem like it's
> likely any worse (and might be *better*) than having it at some block
> boundary due to alignment...
>
> Hmm?
The default inode size is 256; and in that case "small files" is less
than 12k. With an ext4 inode size of 1024 bytes "small files" would
be 108k --- and this is ignoring the size of the fsverity header.
With the header these numbers would be even smaller --- and given that
the most common use of this will be for APK and executables, using the
inline data (or inline xattrs) is really not practical.
- Ted
prev parent reply other threads:[~2019-01-29 15:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 5:15 Proposal: A new fs-verity interface Theodore Y. Ts'o
2019-01-10 5:15 ` Theodore Y. Ts'o
2019-01-10 18:18 ` Darrick J. Wong
2019-01-10 18:18 ` Darrick J. Wong
2019-01-14 23:41 ` Dave Chinner
2019-01-14 23:41 ` Dave Chinner
2019-01-23 5:10 ` Theodore Y. Ts'o
2019-01-24 21:25 ` Dave Chinner
2019-01-24 21:40 ` Linus Torvalds
2019-01-24 23:22 ` Theodore Y. Ts'o
2019-01-25 0:32 ` Matthew Wilcox
2019-01-25 0:35 ` Linus Torvalds
2019-01-29 15:48 ` Theodore Y. Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190129154839.GA4421@mit.edu \
--to=tytso@mit.edu \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=ebiggers@kernel.org \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).