OSDev.org

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.

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.

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.

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!)

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!

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.

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.