On 12/17/21 05:06, Christian Brauner wrote:
On Thu, Dec 16, 2021 at 04:00:40PM -0500, Stefan Berger wrote:
But that could still mean a lot of contention on iint->mutex since this
lock is global, i.e. in this context: for all ima namespaces. You might
want to consider coming up with some rough ideas for how to solve this
_if_ this becomes a problem in the future.
The plan is that each IMA namespace will have its own rbtree with its own
set of iints. We cannot do it all at the same time, so this will take while
until things can be completely moved over into a per-IMA namespace rbtree
and each IMA namespace becomes fully independent.
Ok, good to hear that you have already thought about that.
Well, yes, we thought about it. However, as far as I can look ahead we
cannot get rid of the iint->mutex:
Obviously we have to organize the data structures where IMA is recording
what it has done with a file/inode in such a way that each namespace can
efficiently determine whether it needs to audit/measure/appraise a file
or re-audit/re-measure/re-appraise it after file modification. The
organization of these data structures also has to reflect the fact that
files can be shared between IMA namespaces via setns() on mount
namespaces or shared files or shared mount namespaces between containers
etc.. So, the first thing we do already is move audit-related flags into
what is called the ns_status (namespace status) structure that are kept
in a per-IMA namespace rbtree. This allows IMA to remember that a file
was already audited and it doesn't need to audit it again. The lookup
via rbtree is quick: O(log(n).
Unfortunately the previous series had a bug so that files were not
re-audited after they were modified. I fixed this now in the new series
(upcoming v8) by connecting each ns_status also to a list. This list
starts in the global inode integrity cache (the iint rbtree) where each
inode that any IMA namespace accessed has an iint entry today. The lists
start on the iint entries representing inodes. When files are deleted
or modified or xattrs are modified then all IMA namespaces need to
re-audit/re-measure/re-appraise the file (depending on policy) and for
this we have to reset flags across all the IMA namespaces by walking the
list of ns_status entries. The organization via iint rbtree and
ns_status list allows for quick lookup of the inode where the
modification happened and quick reset of the flags: O(log(n)) + O(n).
This is better than having to search all namespaces to reset the flags
(O(log(n) * n) if there was no list.
Stefan
