On 8/25/20 8:20 AM, Ondrej Mosnacek wrote:
Hi Ondrej,
I am just trying understand the expected behavior w.r.t the usage of
rcu_dereference_protected() for accessing SELinux policy. Could you
please clarify?
Instead of holding the RCU read lock the whole time while accessing the
policy, add a simple refcount mechanism to track its lifetime. After
this, the RCU read lock is held only for a brief time when fetching the
policy pointer and incrementing the refcount. The policy struct is then
guaranteed to stay alive until the refcount is decremented.
Freeing of the policy remains the responsibility of the task that does
the policy reload. In case the refcount drops to zero in a different
task, the policy load task is notified via a completion.
The advantage of this change is that the operations that access the
policy can now do sleeping allocations, since they don't need to hold
the RCU read lock anymore. This patch so far only leverages this in
security_read_policy() for the vmalloc_user() allocation (although this
function is always called under fsi->mutex and could just access the
policy pointer directly). The conversion of affected GFP_ATOMIC
allocations to GFP_KERNEL is left for a later patch, since auditing
which code paths may still need GFP_ATOMIC is not very easy.
Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
---
security/selinux/ss/services.c | 286 ++++++++++++++++-----------------
security/selinux/ss/services.h | 6 +
2 files changed, 147 insertions(+), 145 deletions(-)
int security_read_policy(struct selinux_state *state,
void **data, size_t *len)
{
struct selinux_policy *policy;
policy = rcu_dereference_protected(
state->policy,
lockdep_is_held(&state->policy_mutex));
if (!policy)
return -EINVAL;
...
}
If "policy_mutex" is not held by the caller of security_read_policy() I
was expecting the above rcu_dereference_protected() call to return NULL,
but policy is non-NULL and I see the following messages in "dmesg" log.
Is this expected?
[ 78.627152] =============================
[ 78.627155] WARNING: suspicious RCU usage
[ 78.627159] 5.9.0-rc1+ #10 Not tainted
[ 78.627162] -----------------------------
[ 78.627166] security/selinux/ss/services.c:3950 suspicious
rcu_dereference_protected() usage!
[ 78.627169]
other info that might help us debug this:
[ 78.627173]
rcu_scheduler_active = 2, debug_locks = 1
[ 78.627177] 1 lock held by bash/2446:
[ 78.627179] #0: ffff939ef5f69448 (sb_writers#7){.+.+}-{0:0}, at:
vfs_write+0x1b8/0x230
[ 78.627199]
stack backtrace:
[ 78.627205] CPU: 10 PID: 2446 Comm: bash Not tainted 5.9.0-rc1+ #10
[ 78.627208] Hardware name: LENOVO 30BFS07500/1036, BIOS S03KT33A
08/06/2019
[ 78.627211] Call Trace:
[ 78.627222] dump_stack+0x9f/0xe5
[ 78.627231] lockdep_rcu_suspicious+0xce/0xf0
[ 78.627256] security_read_policy_kernel+0x10a/0x140
[ 78.627268] selinux_measure_state+0x1dc/0x270
[ 78.627282] sel_write_checkreqprot+0x129/0x1a0
[ 78.627296] vfs_write+0xdd/0x230
[ 78.627300] ? sel_read_handle_unknown+0xb0/0xb0
[ 78.627304] ? vfs_write+0xdd/0x230
[ 78.627313] ksys_write+0xad/0xf0
[ 78.627324] __x64_sys_write+0x1a/0x20
[ 78.627333] do_syscall_64+0x37/0x80
[ 78.627341] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 78.627346] RIP: 0033:0x7faabb210264
[ 78.627351] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00
00 00 00 66 90 48 8d 05 a1 06 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
thanks,
-lakshmi
