Re: [PATCH v10 18/27] integrity/ima: Define ns_status for storing namespaced iint data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2022-02-01 at 15:37 -0500, Stefan Berger wrote:
> From: Mehmet Kayaalp <mkayaalp@xxxxxxxxxxxxxxxxxx>
> 
> Add an rbtree to the IMA namespace structure that stores a namespaced
> version of iint->flags in ns_status struct. Similar to the
> integrity_iint_cache, both the iint and ns_status are looked up using the
> inode pointer value. The lookup, allocate, and insertion code is also
> similar.
> 
> In subsequent patches we will have to find all ns_status entries an iint
> is being used in and reset flags there. To do this, connect a list of
> ns_status to the integrity_iint_cache and provide a reader-writer
> lock in the integrity_iint_cache to lock access to the list.
> 
> To simplify the code in the non-namespaces case embed an ns_status in
> the integrity_iint_cache and have it linked into the iint's ns_status list
> when calling ima_get_ns_status().
> 
> When getting an ns_status first try to find it in the RB tree. Here we can
> run into the situation that an ns_status found in the RB tree has a
> different iint associated with it for the same inode. In this case we need
> to delete the ns_status structure and get a new one.
> 
> There are two cases for freeing:
> - when the iint is freed (inode deletion): Walk the list of ns_status
>   entries and disconnect each ns_status from the list; take the
>   writer lock to protect access to the list; also, take the item off the
>   per-namespace rbtree
> 
> - when the ima_namepace is freed: While walking the rbtree, remove the
>   ns_status from the list while also holding the iint's writer lock;
>   to be able to grab the lock we have to have a pointer to the iint on
>   the ns_status structure.
> 
> To avoid an ns_status to be freed by the two cases concurrently, prevent
> these two cases to run concurrently. Therefore, groups of threads
> deleting either inodes or ima_namespaces are allowed to run concurrently
> but no two threads may run and one delete an inode and the other an
> ima_namespace.

The locking involved here is really complex.  I'm sure you thought
about it a lot, but isn't there a better alternative?

> 
> Signed-off-by: Mehmet Kayaalp <mkayaalp@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxxxxx>
> 
> ---
> v9:
>  - Move ns_status into integrity.h and embedded it into integrity_iint_cache
>    for the non-CONFIG_IMA_NS case

<snip>

>  
> +/*
> + * ima_free_ns_status_tree - free all items on the ns_status_tree and take each
> + *                           one off the list; yield to ns_list free'ers
> + *
> + * This function is called when an ima_namespace is freed. All entries in the
> + * rbtree will be taken off their list and collected in a garbage collection
> + * list and freed at the end. This allows to walk the rbtree again.
> + */
> +void ima_free_ns_status_tree(struct ima_namespace *ns)
> +{
> +	struct ns_status *ns_status, *next;
> +	struct llist_node *node;
> +	LLIST_HEAD(garbage);
> +	unsigned int ctr;
> +	bool restart;
> +
> +	do {
> +		ctr = 0;
> +		restart = false;
> +
> +		lock_group(GRP_NS_STATUS_TREE);
> +		write_lock(&ns->ns_tree_lock);
> +
> +		rbtree_postorder_for_each_entry_safe(ns_status, next,
> +						     &ns->ns_status_tree,
> +						     rb_node) {
> +			write_lock(&ns_status->iint->ns_list_lock);
> +			if (!list_empty(&ns_status->ns_next)) {
> +				list_del_init(&ns_status->ns_next);
> +				llist_add(&ns_status->gc_llist, &garbage);
> +				ctr++;
> +			}

At this point when the namespace is being deleted, no entries are being
added to the rbtree, so it is safe to remove the nodes here.  There's
no need to first create a list and then remove them.

> +			write_unlock(&ns_status->iint->ns_list_lock);
> +
> +			/*
> +			 * After some progress yield to any waiting ns_list
> +			 * free'ers.
> +			 */
> +			if (atomic_read(&ns_list_waiters) > 0 && ctr >= 5) {
> +				restart = true;
> +				break;
> +			}

Giving priority to removing entries in the iint cache is important, but
I wish there was a better alternative.

> +		}
> +
> +		write_unlock(&ns->ns_tree_lock);
> +		unlock_group(GRP_NS_STATUS_TREE);
> +	} while (restart);
> +
> +	node = llist_del_all(&garbage);
> +	llist_for_each_entry_safe(ns_status, next, node, gc_llist)
> +		ns_status_free(ns, ns_status);
> +
> +	kmem_cache_destroy(ns->ns_status_cache);
> +}

-- 
thanks,

Mimi




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux