OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:16 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Mon Jun 18, 2007 10:26 am 
Offline
Member
Member

Joined: Sat Jun 02, 2007 10:35 am
Posts: 28
Quote:
How about having the handle structure stored in the relevant process'es memory, which is written to by the kernel?


If the queue data are in a kernel page, then a transition to ring 0 would be required in order to modify the values.

Quote:
There are two things you have to ensure:
1) Each process knows for certain the identity of the process sending messages to it (and the sender must not be able to fake their identity!)


Why should a receiver know the identity of the sender? even if a dialog between sender and receiver is required, the dialog could be achieved using return values instead of exchanging messages.

Quote:
2) No process can write to another's shared memory OR to where the recieving process 'thinks' the sending process is writing to.

The second of these could have some interesting problems - for instance:
- Process A is about to read the last page of some memory shared with Process B, and is then subjected to a context switch
- Process B then resizes its shared memory, decreasing its size and loosing the last page, that Process A was about to read.
- Process E (E for evil >Smile ) then increases its buffer size, and the new page is placed where B's old one was.
- Process A will then read information written by E, that it thinks comes from B


Process A will not be able to read from a non-existent page. Upon B's resizing, the page will be marked non-existent for A.

The simplest solution I see is that the O/S allocates a shared memory buffer between two processes. The treatment of the shared buffer should be left entirely to the processes themselves.

The buffers should be allocated in such a way that buffer overrun or underrun is minimized, if possibly caught. This can be achieved by inserting guard pages between the buffers.

I think the only realistic solution for a modularized O/S is user-defined security: CPUs should have allowed the execution of a user-defined function upon access of another page. The function would be cached on the CPU, allowing for efficient and superfast access control. The kernel would be responsible for loading the security check code.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 23, 2007 4:12 pm 
Offline
Member
Member

Joined: Mon Mar 27, 2006 12:00 am
Posts: 59
Location: UK
Quote:
If the queue data are in a kernel page, then a transition to ring 0 would be required in order to modify the values.

Well yes, but not to read them - which should speed things up a little (if not a lot!)

Quote:
Why should a receiver know the identity of the sender? even if a dialog between sender and receiver is required, the dialog could be achieved using return values instead of exchanging messages.

To have security, a process must decide what operations it wishes to perform when asked by another process. To find the security privalledges of a process, you need to know its identity!


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 25, 2007 10:11 pm 
Offline
Member
Member

Joined: Thu Oct 21, 2004 11:00 pm
Posts: 248
Actually, the receiver only needs a value that codes for the security privileges of the sender. This value need not uniquely identify the sender.

For example, L4.sec implements message passing using "endpoints", two way channels for messages to which threads can listen and send. A thread doesn't receive the identity of the sender of a message under this system, it receives the security "badge" of the endpoint from which the message came.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 01, 2007 7:56 am 
Offline
Member
Member

Joined: Mon Mar 27, 2006 12:00 am
Posts: 59
Location: UK
Crazed123 wrote:
Actually, the receiver only needs a value that codes for the security privileges of the sender. This value need not uniquely identify the sender.

For example, L4.sec implements message passing using "endpoints", two way channels for messages to which threads can listen and send. A thread doesn't receive the identity of the sender of a message under this system, it receives the security "badge" of the endpoint from which the message came.

That's a point! I think what I said still applies though - if the reciever thinks a page is being written to by a process by a certain security "badge", when in fact it is not, then the security of that process is compromised. Basically what I was saying is that you need to give proccesses a simple and cheap (in terms of time) method of knowing whether the sender has changed the buffer size.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 20 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group