linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: serge@hallyn.com
To: Tony Jones <tonyj@immunix.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch 5/12] lsm stacking v0.2: actual stacker module
Date: Tue, 5 Jul 2005 13:17:27 -0500	[thread overview]
Message-ID: <20050705181727.GA5209@vino.hallyn.com> (raw)
In-Reply-To: <20050704204155.GA30210@immunix.com>

Quoting Tony Jones (tonyj@immunix.com):
> I'm going to have to give it some thought, but a new rmmod hook does seem
> a good solution off the top of my head.

In reponse to some prodding by Tony, here is a summary of the current
locking scheme in stacker, sprinkled with some notes about one way lsm
removal could be supported.

This will likely be added to the Documentation/stacker.txt file.

thanks,
-serge

The following describes the locking used by the lsm stacker as of
July 1, 2005:

Things which require locking include:

	1. module list
	2. per-kernel-object security lists

The module list is protected as follows:

	Walking the list is done under a partial rcu_read_lock.  In
	particular, we cannot hold the rcu_read_lock while calling a
	module_entry->lsm_hook(), as these are very likely to sleep.
	Therefore we call rcu_read_lock() only when we rcu_dereference
	module_entry->next.

	module_entries are not to be deleted.  By using the
	stacker_unload() function, they may be removed from the
	stacked_modules list.  The forward pointer is not changed, so
	that any stacker hook which is currently on module_entry
	can safely and correctly dereference module_entry->next.
	The module_entry remains on the all_modules list, which is
	used when kernel objects are freed.  In this way, any memory
	allocated by module_entry can still be freed.

	In the past, module deletion was supported in this scheme as
	follows: we added a reference count to the module_entry,
	which was incremented (under the rcu_read_lock) whenever a
	stacker hook was going to execute module_entry->lsm_hook().
	Module deletion was then done from a call_rcu().  If the
	refcount was not null after an rcu cycle, the del_func could
	delete the module.  Otherwise, it decremented the usage count,
	so that when the stacker hook returned from lsm_hook() it would
	find the refcount at 1, and delete the module.

	Re-enabling module deletion in this way should have a performance
	impact, and would require all modules to delete all their
	allocated kernel memory during module_exit().

The kernel object security lists are protected as follows:

	The security_set_value and security_del_value are only to
	be called during security_alloc_object and security_del_object,
	respectively.  Since these are automatically safe from
	concurrent accesses, no locking is required here.

	The security_add_value() function is protected from concurrent
	access using the stacker_value_spinlock.  security_get_value()
	is protected from security_add_value() using rcu.

	To allow module deletion, it would be desirable for modules
	to be able to delete kernel object security entries at any
	time.  This should be safe to do using RCU.  Modules would use
	security_unlink_value(), which would use hlist_del_rcu() to free
	the value, and LSMs would have to use call_rcu() to free the
	data in order to protect racing security_get_value()s.  This
	would happen as follows:

	1. security_unlink_value() would basically be security_del_value
	protected using the stacker_value_spinlock().
	2. An LSM would delete a value using:

		my_struct = security_unlink_value_type(&inode->i_security,
				MY_LSM_ID, struct my_struct);
		< do any necessary freeing of LSM data>
		security_free_value_type(my_struct);
	3. security_free_value_type would use call_rcu to kfree my_struct.

  reply	other threads:[~2005-07-05 18:19 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-30 19:44 [patch 0/12] lsm stacking v0.2: intro serue
2005-06-30 19:48 ` [patch 1/12] lsm stacking v0.2: don't default to dummy_##hook serue
2005-06-30 19:48 ` [patch 2/12] lsm stacking v0.2: replace void* security with hlist serue
2005-06-30 19:49 ` [patch 3/12] lsm stacking v0.2: introduce security_*_value API serue
2005-06-30 19:49 ` [patch 4/12] lsm stacking v0.2: stacker documentation serue
2005-06-30 19:50 ` [patch 5/12] lsm stacking v0.2: actual stacker module serue
2005-07-01  2:32   ` James Morris
2005-07-01 19:24     ` serge
2005-07-01 20:35   ` Greg KH
2005-07-03  0:24     ` serge
2005-07-03 18:25       ` Tony Jones
2005-07-03 18:53         ` James Morris
2005-07-03 19:09           ` Tony Jones
2005-07-03 20:44           ` [PATCH] securityfs Greg KH
2005-07-04 12:39             ` serge
2005-07-04 15:53             ` serge
2005-07-05  6:07               ` Greg KH
2005-07-06 12:25                 ` serge
2005-07-06  6:52             ` James Morris
2005-07-06  7:04               ` Greg KH
2005-07-06 12:29               ` Stephen Smalley
2005-07-06 15:35                 ` James Morris
2005-07-06 16:06                   ` Stephen Smalley
2005-07-06 16:16                     ` Greg KH
2005-07-06 18:01                     ` Chris Wright
2005-07-06 22:08             ` serue
2005-07-06 22:22               ` Greg KH
2005-07-06 23:32                 ` serge
2005-07-07 17:30                 ` serge
2005-07-07 17:48                   ` Greg KH
2005-07-07 18:27                     ` serue
2005-07-07 22:46                       ` serge
2005-07-07 23:06                         ` Greg KH
2005-07-07 23:12                           ` serue
2005-07-08 20:44                           ` serue
2005-07-08 20:49                             ` Greg KH
2005-07-08 21:03                               ` Chris Wright
2005-07-04  3:18   ` [patch 5/12] lsm stacking v0.2: actual stacker module Tony Jones
2005-07-04 11:51     ` serge
2005-07-04 19:37       ` Tony Jones
2005-07-04 20:06         ` serge
2005-07-04 20:41           ` Tony Jones
2005-07-05 18:17             ` serge [this message]
2005-07-08 21:43     ` serue
2005-07-08 22:12       ` serue
2005-07-11 14:40   ` Stephen Smalley
2005-07-11 17:51     ` serue
2005-07-11 19:03       ` Stephen Smalley
2005-07-13 16:39     ` serue
2005-07-13 18:27       ` serue
2005-06-30 19:51 ` [patch 6/12] lsm stacking v0.2: stackable capability lsm serue
2005-06-30 19:52 ` [patch 7/12] lsm stacking v0.2: selinux: update security structs serue
2005-06-30 19:53 ` [patch 8/12] lsm stacking v0.2: selinux: use security_*_value API serue
2005-06-30 19:53 ` [patch 9/12] lsm stacking v0.2: selinux: remove secondary support serue
2005-06-30 19:54 ` [patch 10/12] lsm stacking v0.2: hook completeness verification serue
2005-06-30 19:55 ` [patch 11/12] lsm stacking v0.2: /proc/$$/attr/ sharing serue
2005-06-30 19:55 ` [patch 12/12] lsm stacking v0.2: update seclvl for stacking serue

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=20050705181727.GA5209@vino.hallyn.com \
    --to=serge@hallyn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tonyj@immunix.com \
    /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).