From: zohar@linux.vnet.ibm.com (Mimi Zohar)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description)
Date: Sun, 17 Sep 2017 01:47:41 -0400 [thread overview]
Message-ID: <1505627261.4200.161.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CA+55aFxmeff53zeioTiQY6m=F18ekgX1-HWZyQUor=NJYrxM9A@mail.gmail.com>
On Sat, 2017-09-16 at 11:20 -0700, Linus Torvalds wrote:
> On Fri, Sep 15, 2017 at 1:25 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> >
> > To resolve this locking problem, this patch defines a new
> > ->integrity_read file operation method, which is equivalent to
> > ->read_iter, except that it will not take the i_rwsem lock, but will
> > be called with the i_rwsem held exclusively.
> >
> > Since taking the i_rwsem exclusively is not required for reading the
> > file in order to calculate the file hash, the code only verifies
> > that the lock has been taken.
>
> Ok, so I'm onboard with the commit message now, but realized that I'm
> not actually convinced that i_rwsem is even meaningful.
>
> Sure, generic_file_write_iter() does take that lock exclusively, but
> not everybody uses generic_file_write_iter() at all for writing.
> For example, xfs still uses that i_rwsem, but for block-aligned writes
> it will only get it shared. And I'm not convinced some other
> filesystem might not end up using some other lock entirely.
>
> So I'm basically not entirely convinced that these i_rwsem games make
> any sense at all.
>
> The filesystem can do its own locking, and I'm starting to think that
> it would be better to just pass this "this is an integrity read" down
> to the filesystem, and expect the filesystem to do the locking based
> on that.
IMA would still need to take the i_rwsem to write the xattr. ?Unless
the i_rwsem was taken before calling the integrity_read, calculating
the file hash would be serialized, but would not prevent the file hash
from being calculated multiple times.
(Introducing a new lock would result in the locks being taken in
reverse order for setxattr, chown, chmod syscalls.)
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LSM List <linux-security-module@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>,
linux-ima-devel@lists.sourceforge.net,
Christoph Hellwig <hch@infradead.org>,
James Morris <jmorris@namei.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthew Garrett <mjg59@srcf.ucam.org>, Jan Kara <jack@suse.com>,
"Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <yuchao0@huawei.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Bob Peterson <rpeterso@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
Dave Kleikamp <shaggy@kernel.org>,
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>,
Mark Fasheh <mfasheh@versity.com>,
Joel Becker <jlbec@evilplan.org>,
Richard Weinberger <richard@nod.at>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Hugh Dickins <hughd@google.com>, Chris Mason <clm@fb.com>
Subject: Re: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description)
Date: Sun, 17 Sep 2017 01:47:41 -0400 [thread overview]
Message-ID: <1505627261.4200.161.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CA+55aFxmeff53zeioTiQY6m=F18ekgX1-HWZyQUor=NJYrxM9A@mail.gmail.com>
On Sat, 2017-09-16 at 11:20 -0700, Linus Torvalds wrote:
> On Fri, Sep 15, 2017 at 1:25 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> >
> > To resolve this locking problem, this patch defines a new
> > ->integrity_read file operation method, which is equivalent to
> > ->read_iter, except that it will not take the i_rwsem lock, but will
> > be called with the i_rwsem held exclusively.
> >
> > Since taking the i_rwsem exclusively is not required for reading the
> > file in order to calculate the file hash, the code only verifies
> > that the lock has been taken.
>
> Ok, so I'm onboard with the commit message now, but realized that I'm
> not actually convinced that i_rwsem is even meaningful.
>
> Sure, generic_file_write_iter() does take that lock exclusively, but
> not everybody uses generic_file_write_iter() at all for writing.
> For example, xfs still uses that i_rwsem, but for block-aligned writes
> it will only get it shared. And I'm not convinced some other
> filesystem might not end up using some other lock entirely.
>
> So I'm basically not entirely convinced that these i_rwsem games make
> any sense at all.
>
> The filesystem can do its own locking, and I'm starting to think that
> it would be better to just pass this "this is an integrity read" down
> to the filesystem, and expect the filesystem to do the locking based
> on that.
IMA would still need to take the i_rwsem to write the xattr. Unless
the i_rwsem was taken before calling the integrity_read, calculating
the file hash would be serialized, but would not prevent the file hash
from being calculated multiple times.
(Introducing a new lock would result in the locks being taken in
reverse order for setxattr, chown, chmod syscalls.)
Mimi
next prev parent reply other threads:[~2017-09-17 5:47 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-15 4:58 [PATCH 0/3] ima: only call integrity_kernel_read to calc file hash Mimi Zohar
2017-09-15 4:58 ` Mimi Zohar
2017-09-15 4:58 ` [PATCH 1/3] vfs: constify path argument to kernel_read_file_from_path Mimi Zohar
2017-09-15 4:58 ` Mimi Zohar
2017-09-15 18:37 ` Linus Torvalds
2017-09-15 18:37 ` Linus Torvalds
2017-09-15 4:58 ` [PATCH 2/3] integrity: replace call to integrity_read_file with kernel version Mimi Zohar
2017-09-15 4:58 ` Mimi Zohar
2017-09-15 4:58 ` [PATCH 3/3] ima: use fs method to read integrity data Mimi Zohar
2017-09-15 4:58 ` Mimi Zohar
[not found] ` <CA+55aFwVujvsdaq09O216u-uBbBbo5i_1d6aw3ksottR_uiJ6w@mail.gmail.com>
2017-09-15 9:04 ` Mimi Zohar
2017-09-15 9:04 ` Mimi Zohar
2017-09-15 9:09 ` Mimi Zohar
2017-09-15 9:09 ` Mimi Zohar
2017-09-15 18:05 ` Linus Torvalds
2017-09-15 18:05 ` Linus Torvalds
2017-09-15 14:49 ` Christoph Hellwig
2017-09-15 14:49 ` Christoph Hellwig
2017-09-15 15:21 ` Mimi Zohar
2017-09-15 15:21 ` Mimi Zohar
2017-09-15 20:25 ` [PATCH 3/3] ima: use fs method to read integrity data (updated patch description) Mimi Zohar
2017-09-15 20:25 ` Mimi Zohar
2017-09-16 18:20 ` Linus Torvalds
2017-09-16 18:20 ` Linus Torvalds
2017-09-17 5:47 ` Mimi Zohar [this message]
2017-09-17 5:47 ` Mimi Zohar
2017-09-17 15:17 ` Christoph Hellwig
2017-09-17 15:17 ` Christoph Hellwig
2017-09-17 15:28 ` Linus Torvalds
2017-09-17 15:28 ` Linus Torvalds
2017-09-17 15:37 ` Christoph Hellwig
2017-09-17 15:37 ` Christoph Hellwig
2017-09-17 16:15 ` Mimi Zohar
2017-09-17 16:15 ` Mimi Zohar
2017-09-17 16:34 ` Linus Torvalds
2017-09-17 16:34 ` Linus Torvalds
2017-09-17 16:38 ` Al Viro
2017-09-17 16:38 ` Al Viro
2017-09-18 9:19 ` Steven Whitehouse
2017-09-18 9:19 ` Steven Whitehouse
2017-09-18 10:13 ` Jan Kara
2017-09-18 10:13 ` Jan Kara
2017-09-18 14:55 ` Mimi Zohar
2017-09-18 14:55 ` Mimi Zohar
2017-09-24 22:55 ` Mimi Zohar
2017-09-24 22:55 ` Mimi Zohar
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=1505627261.4200.161.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=linux-security-module@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.