threads

threads

[Albert Cahalan]

Normal Linux security data (uid, capability bits)
is per-thread. There are at least two reasons for
this:

1. Multi-threaded server daemons can rely on
   kernel-enforced security.

2. Race conditions are eliminated without locking.
   This deals with the problem of two threads
   simultaneously updating the security data, or
   one thread updating while another thread uses.

I'm told that SE Linux enforces shared security
data. I suppose this is mostly required when
implementing a mandatory system. Is this race-free?
Is there a capability that would allow a suitably
privileged process to have per-thread contexts?

Also, I'm told that a security context can only
change during exec. WHAT???? Besides the case of
a suitably privileged process, what about the
need to move some sort of watermark? AFAIK, your
security context needs to be tainted when you
read low-integrity data and so on.




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: threads

[Stephen Smalley]

On Fri, 2003-12-26 at 10:54, Albert Cahalan wrote:
> Normal Linux security data (uid, capability bits)
> is per-thread. There are at least two reasons for
> this:
> 
> 1. Multi-threaded server daemons can rely on
>    kernel-enforced security.
> 
> 2. Race conditions are eliminated without locking.
>    This deals with the problem of two threads
>    simultaneously updating the security data, or
>    one thread updating while another thread uses.
> 
> I'm told that SE Linux enforces shared security
> data. I suppose this is mostly required when
> implementing a mandatory system. Is this race-free?
> Is there a capability that would allow a suitably
> privileged process to have per-thread contexts?

For MAC, per-thread contexts make little sense since you cannot enforce
any separation of the memory.

> Also, I'm told that a security context can only
> change during exec. WHAT???? Besides the case of
> a suitably privileged process, what about the
> need to move some sort of watermark? AFAIK, your
> security context needs to be tainted when you
> read low-integrity data and so on.

Limiting security context transitions to execve allows the inheritance
of state between the contexts and the initialization of the process in
the new security context to be precisely controlled, including the
particular entrypoint program used to enter the new context. A
setuid(2)-like call for contexts would lack such controls and would
provide no real separation between the two contexts. Introducing such an
operation into the system would yield two different sets of controls and
behaviors for context transitions.
The omission of such an operation from SELinux was noted in the original
design documentation, and has been discussed on the list before.

With regard to "tainting", you are thinking about it the wrong way.  A
high integrity process shouldn't be allowed to read low integrity data
(if that is your security goal), not magically migrated to a low
integrity label upon performing such a read.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: threads

[Albert Cahalan]

On Mon, 2003-12-29 at 10:37, Stephen Smalley wrote:
> On Fri, 2003-12-26 at 10:54, Albert Cahalan wrote:
> > Normal Linux security data (uid, capability bits)
> > is per-thread. There are at least two reasons for
> > this:
> > 
> > 1. Multi-threaded server daemons can rely on
> >    kernel-enforced security.
> > 
> > 2. Race conditions are eliminated without locking.
> >    This deals with the problem of two threads
> >    simultaneously updating the security data, or
> >    one thread updating while another thread uses.
> > 
> > I'm told that SE Linux enforces shared security
> > data. I suppose this is mostly required when
> > implementing a mandatory system. Is this race-free?
> > Is there a capability that would allow a suitably
> > privileged process to have per-thread contexts?
> 
> For MAC, per-thread contexts make little sense
> since you cannot enforce any separation of the memory.

This is not quite right. A server daemon using
per-thread contexts is clearly within your trusted
computing base, just as the kernel is. This can
improve security over the obvious alternative of
having the server run in a context that can do
anything.

> > Also, I'm told that a security context can only
> > change during exec. WHAT???? Besides the case of
> > a suitably privileged process, what about the
> > need to move some sort of watermark? AFAIK, your
> > security context needs to be tainted when you
> > read low-integrity data and so on.
> 
> Limiting security context transitions to execve allows the inheritance
> of state between the contexts and the initialization of the process in
> the new security context to be precisely controlled, including the
> particular entrypoint program used to enter the new context. A
> setuid(2)-like call for contexts would lack such controls and would
> provide no real separation between the two contexts. Introducing such an
> operation into the system would yield two different sets of controls and
> behaviors for context transitions.
> The omission of such an operation from SELinux was noted in the original
> design documentation, and has been discussed on the list before.

I was assuming you wouldn't hand out such
privilige willy-nilly.


> With regard to "tainting", you are thinking about it the wrong way.  A
> high integrity process shouldn't be allowed to read low integrity data
> (if that is your security goal), not magically migrated to a low
> integrity label upon performing such a read.

Isn't this the way LOMAC works?



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: threads

[Russell Coker]

On Wed, 21 Jan 2004 12:11, Albert Cahalan <albert@users.sourceforge.net> 
wrote:
> > For MAC, per-thread contexts make little sense
> > since you cannot enforce any separation of the memory.
>
> This is not quite right. A server daemon using
> per-thread contexts is clearly within your trusted
> computing base, just as the kernel is. This can
> improve security over the obvious alternative of
> having the server run in a context that can do
> anything.

Also having threads in different contexts may be helpful for file servers.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: threads

[Stephen Smalley]

On Tue, 2004-01-20 at 20:11, Albert Cahalan wrote:
> This is not quite right. A server daemon using
> per-thread contexts is clearly within your trusted
> computing base, just as the kernel is. This can
> improve security over the obvious alternative of
> having the server run in a context that can do
> anything.

With such a model, you'll quickly end up with everything in your TCB and
your system will be just as easily broken as before.  Split your daemon
into multiple processes running in different contexts instead.  Improve
security?  No, just provide an illusion of it; no real separation is
ensured.

> I was assuming you wouldn't hand out such
> privilige willy-nilly.

Once such a capability exists, people will use it for everything, and
never even consider proper decomposition of their daemons.

> Isn't this the way LOMAC works?

Yes.  But that doesn't mean it is a good idea.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

threads

[Fabio Andres Miranda]

Why these threads are not executed:


main(){
    pthread threads_array[25];
    pthread_attr_init(&attr);
    for (i=0;i<25;i++)
        if ( pthread_create(threads_array[i],&attr,pthread_routine,(void 
*)i) ){
            perror("pthread_create");
        }
    while(1);
}


void
pthread_routine(void *arg){
    printf("hello world\n");
}

$./a.out
$

I read somethg about the initial state is suspended, smthg like that, 
how to execute the thread as created then?

Thanks

fabiolini

Re: threads

[Steve Graegert]

On 11/6/05, Fabio Andres Miranda <fabiomiranda@racsa.co.cr> wrote:
> Why these threads are not executed:
>
>
> main(){
>     pthread threads_array[25];
>     pthread_attr_init(&attr);
>     for (i=0;i<25;i++)
>         if ( pthread_create(threads_array[i],&attr,pthread_routine,(void
> *)i) ){
>             perror("pthread_create");
>         }
>     while(1);
> }
>
>
> void
> pthread_routine(void *arg){
>     printf("hello world\n");
> }

Fabio,

This code will not even compile.  I suppose you did not post the
complete program.  Anyway, there are at least two points (probably
more) broken in your code:

1.  You have to provide pthread_create a pointer to the thread_t object:

	pthread_create(&threads_array[i], ...);

2.  The thread function needs to be a pointer to a function:

	void *pthread_routine(void *arg);

3.  Omit the while statement, since the program will run forever,
although all threads have finished.

Try this:

#include <pthread.h>

void *pthread_routine(void *arg);
pthread_attr_t attr;

main(){
   pthread_t threads_array[25];
   pthread_attr_init(&attr);

   int i;
   for (i=0;i<25;i++)
       if ( pthread_create(&threads_array[i],&attr,pthread_routine,(void
*)i) ) {
           perror("pthread_create");
       }
   while(1);
}


void *pthread_routine(void *arg){
   printf("hello world\n");
}

	\Steve

(no subject)

[Ying Chen]

Hi,

I have two questions on Linux pthread related issues. Would anyone be able 
to help?

1. Does any one have some suggestions (pointers) on good kernel Linux thread 
libraries?
2. We ran multi-threaded application using Linux pthread library on 2-way 
SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see 
significant increase in context switching when moving from UP to SMP, and 
high CPU usage with no performance gain in turns of actual work being done 
when moving to SMP, despite the fact the benchmark we are running is 
CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks 
went to scheduling and signaling overheads. Has anyone seen something like 
this before with pthread applications running on SMP platforms? Any 
suggestions or pointers on this subject?

Thanks a lot!

Ying



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: threads

[J . A . Magallon]

On 03.07 Ying Chen wrote:
> 2. We ran multi-threaded application using Linux pthread library on 2-way 
> SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see 
> significant increase in context switching when moving from UP to SMP, and 
> high CPU usage with no performance gain in turns of actual work being done 
> when moving to SMP, despite the fact the benchmark we are running is 
> CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks 
> went to scheduling and signaling overheads. Has anyone seen something like 
> this before with pthread applications running on SMP platforms? Any 
> suggestions or pointers on this subject?
> 

Too much contention ? How frequently do you create and destroy threads ?
How much frequently do they access shared-writable-data ?
How do you protect them ?

It seems like your system spents more time creating and killing threads
that doing real work.

-- 
J.A. Magallon                                                      $> cd pub
mailto:jamagallon@able.es                                          $> more beer

Linux werewolf 2.4.2-ac13 #3 SMP Wed Mar 7 00:09:17 CET 2001 i686

threads

[M.Kiran Babu]

 sir,
i got some doubts in kernel
programming. i am using linux 6.1 version. i want to use threads in
kernel.is it possible to use pthreads in kernel. there is one more
function kernel_thread. can i use
that function. if i use that function how to get synchonization. inmany
files it was used. but everywhere lock_kernel() and unlock_kernel()
functions are being used. if we use that commands the whole kernel gets
locked. is there any other mechanisms. or can i use that methods only. if
i can use these methods what is the syntax of kernel_thread function. the
arguments that are passing to these function are 3. i dont know what are
those three. please  tell me.
				




                                               
                        
               




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: threads

[Matti Aarnio]

On Fri, Nov 10, 2000 at 08:33:29PM +0530, M.Kiran Babu wrote:
>  sir,
> i got some doubts in kernel
> programming. i am using linux 6.1 version. i want to use threads in

	Linux kernel versions are now running up to 2.4.0*, what is
	that 6.1 ?  Some distribution ?  Which ?
	Which kernel version you are referring into ?

> kernel.is it possible to use pthreads in kernel. there is one more
                               ^^^^^^^^^^^^^^^^^^   NO.
> function kernel_thread.
> can i use that function.

	#include <asm/processor.h>

	extern pid_t kernel_thread(int (*fn)(void *), void * arg,
				   unsigned long flags);

> if i use that function how to get synchonization.

	With mutexes, waitqueues, or spinlocks.
	All kernel facilities.

> inmany files it was used. but everywhere lock_kernel() and unlock_kernel()
> functions are being used. if we use that commands the whole kernel gets
> locked.

	Really ?  Who says you need to   lock_kernel()  for starting
	a kernel thread ?

> is there any other mechanisms. or can i use that methods only.
> if i can use these methods what is the syntax of kernel_thread function.
> the arguments that are passing to these function are 3.
> i dont know what are those three. please tell me.

	Pick 2.4.0 sources, open them up.

	Then do:  "make psdocs" or "make pdfdocs" or "make htmldocs"
	and you get up documents from within the system into your
	source location Documentation/DocBook/  subdirectory.

	You propably want to study  kernel-hacking,  kernel-locking,
	and  kernel-api   documents.

	(Your system needs to have DocBook, related SGML tools, and
	 (for PS/PDF) (La)TeX subsystem.)

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: threads

[Reto Baettig]

lock_kernel is a special case and will not block when you call it in
order to create a new kernel thread. Look at the implementation of
lock_kernel if you have any doubts (this is true for the 2.2 kernels. I
don't know it by heart for the 2.4 kernel). 

	Reto

"M.Kiran Babu" wrote:
> 
>  sir,
> i got some doubts in kernel
> programming. i am using linux 6.1 version. i want to use threads in
> kernel.is it possible to use pthreads in kernel. there is one more
> function kernel_thread. can i use
> that function. if i use that function how to get synchonization. inmany
> files it was used. but everywhere lock_kernel() and unlock_kernel()
> functions are being used. if we use that commands the whole kernel gets
> locked. is there any other mechanisms. or can i use that methods only. if
> i can use these methods what is the syntax of kernel_thread function. the
> arguments that are passing to these function are 3. i dont know what are
> those three. please  tell me.
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/