Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1308978 > unrolled thread

Walking a wait_queue_t list of tasks blocked on pipe

Started by"W. Michael Petullo" <mike@flyn.org>
First post2016-01-14 04:40 +0100
Last post2016-01-14 22:50 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel


Contents

  Walking a wait_queue_t list of tasks blocked on pipe "W. Michael Petullo" <mike@flyn.org> - 2016-01-14 04:40 +0100
    Re: Walking a wait_queue_t list of tasks blocked on pipe Christoph Hellwig <hch@infradead.org> - 2016-01-14 09:40 +0100
      Re: Walking a wait_queue_t list of tasks blocked on pipe "W. Michael Petullo" <mike@flyn.org> - 2016-01-14 22:50 +0100

#1308978 — Walking a wait_queue_t list of tasks blocked on pipe

From"W. Michael Petullo" <mike@flyn.org>
Date2016-01-14 04:40 +0100
SubjectWalking a wait_queue_t list of tasks blocked on pipe
Message-ID<qQGVr-16B-7@gated-at.bofh.it>
I am trying to write code to walk a wait_queue_t list as part of a LSM
file_permission function. The purpose is to act on each task which has
blocked while trying to read from a pipe.

I modeled my code on __wake_up_common() in kernel/sched/core.c, and it
looks something like this:

	// i_pipe is a struct pipe_inode_info *

	if (i_pipe->reader <= 0) {
		return;
	}

	list_for_each_entry_safe(curr, next, &i_pipe->wait.task, task_list) {
		[...]
		struct task_struct *blocked = curr->private;
		[...]
	}

I am not updating the list itself. I am merely setting a value within
each task_struct's security object.

I have tried to wrap my code with this:

	pipe_lock(i_pipe)
	pipe_unlock[...]

this:

	write_lock_irq(&tasklist_lock)
	write_unlock_irq[...]

and also this:

	spin_lock_irqsave(&i_pipe->wait.lock, flags)
	spin_unlock_irqrestore[...]

Despite these locks, I sometimes find that blocked (AKA curr->private) ==
NULL during an iteration of the list_for_each_entry_safe loop, and this
surprises me. Somme memory corruption errors also seem to indicate that
sometimes blocked contains an invalid pointer other than NULL. Why would
there be en entry in the wait_queue_t list which does not have a process
associated with it? Is the data structure moving out from under me? Is
there something else I should lock?

Thank you,

--
Mike

:wq

[toc] | [next] | [standalone]


#1309074

FromChristoph Hellwig <hch@infradead.org>
Date2016-01-14 09:40 +0100
Message-ID<qQLBM-4uu-7@gated-at.bofh.it>
In reply to#1308978
On Wed, Jan 13, 2016 at 10:30:19PM -0500, W. Michael Petullo wrote:
> I am trying to write code to walk a wait_queue_t list as part of a LSM
> file_permission function. The purpose is to act on each task which has
> blocked while trying to read from a pipe.

Just don't do that..

[toc] | [prev] | [next] | [standalone]


#1309678

From"W. Michael Petullo" <mike@flyn.org>
Date2016-01-14 22:50 +0100
Message-ID<qQXWj-4xw-39@gated-at.bofh.it>
In reply to#1309074
>> I am trying to write code to walk a wait_queue_t list as part of a LSM
>> file_permission function. The purpose is to act on each task which has
>> blocked while trying to read from a pipe.
 
> Just don't do that..

What we are trying to do is implement a research prototype for a simple
information-flow system using LSM. The idea is that processes become
tainted when they read objects marked as confidential and such processes
taint other processes based on further interaction.

The problem is that process A could open and block on reading
FIFO F before tainted process B writes to F (and causes F to become
confidential). Since A's LSM hooks fire off before it blocks, A could
end up reading confidential data without itself being tainted.

So it seems that I need to either walk the list of blocked processes,
possibly tainting them, or insert a new LSM hook into pipe.c to support
rechecking the confidentiality level of the pipe after waking up but
before reading.

If this all seems a little crazy it is because we are early in the
prototyping process.

Thank you,

-- 
Mike

:wq

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web