NOTE: Essentially all questions on this test can be answered briefly. There are no long essay questions here!
This exam is worth 30% of the final grade (30 points; allocate 4 minutes per point).
Background: Several questions on this exam relate to the example distributed kernel distributed with the study questions. The following text is lifted verbatim from the study questions:
Consider an operating system similar to Demos and Amoeba. Like Demos, it supports unconstrained message passing between processes. Like Amoeba, it is based on server side authentication. Capabilities have the following form:EMPHATICALLY: The above message passing primitives are the only kernel calls provided by the system. All other operations are performed by communicating with servers using these primitives!_______________________________ | destination ID | index | key | |_________________|_______|_____|The kernel uses destination ID to route messages to their recipients. The kernel makes no use of the index or key fields. Typically, servers will use the index field to identify an object, and will use the key field to validate the capability for the object.Typically, user processes will validate capabilities by checking to see that table[index]=key, where the index and key are taken from the capability presented with a message, and where table is local to the process that is checking the validity. Note that no trapdoor function is involved here.
The destination ID is not a process id. The right of a process to receive messages addressed to a particular destination is controlled as follows: The kernel cooperates with a special server, the registration server. The registration server supports the following operations:
The following message passing primitives are provided:
- create destination ID
- any process can do this at any time
Returns a new capability for a newly allocated destination ID. The index field is the new destination ID The key field is used to validate the right to accept messages addressed to that destination.
- register destination ID
- legal only if the key is the correct key for the destination.
The most recent process to register some destination ID will receive all messages addressed to that destination. The registration server distributes destination ID information to the kernels of all member computers.
- send( cap, buf, len )
- uses the destination ID of cap to send a len-byte message from the buffer given to the most recent process that registered that destination ID. Message delivery is not guaranteed. Message loss may be caused by network problems, lack of buffer capacity, etc.
- receive( &cap, buf, len, &reallen, time )
- await any message addressed to the current process, and place it in buf, up to len bytes. Returns the number of bytes in reallen, and returns the capability for the sender in cap. Time gives the maximum time to wait before returning. This may be zero, in which case, this service returns immediately, giving a message only if one was already enqueued, and it may be infinity, giving the usual semantics for a blocking receive.
In addition to the previously distributed study questions, consider the following outline of a client-side remote method invocation stub for this system:
global variables within client trans-id -- an integer, initially zero return-ID -- a destination ID registered for this process invoke( object-cap, method, params, result ) trans-id = trans-id + 1 trans-key = random return-cap = make-capability( destination-ID = return-ID index = trans-id key = trans-key ) send-buf = [ method | return-cap | params ] repeat send( object-cap, send-buf, length[send-buf] ) receive( &reply-cap, reply-buf, reply-buf-len, &reallen, delay ) until all of the following are true not timeout reply-cap.destination-ID = return-ID reply-cap.index = trans-id reply-cap.key = trans-key result = reply-bufThe above outline is intended to be complete and formally correct, assuming that the delay specified on the receive command is for an appropriate time interval.
Part B: In the above client-side stub, why is the random trans-key sufficient for reply capability validation without the need for the full generality of the table a server would use to validate requests? (2 points)
Part C: Assume this client-side stub is used within one server to call on the services of a secondary server. Why is there no need to save and enqueue incoming messages that have some other destination-ID, or some other index than the expected values? (We devoted half a lecture to the subject of how to build such a system of queues, and each Demos mailbox represented such a queue!) (2 points)
Part D: Suppose we added the queueing mechanism that we showed, in part C, to be unnecessary. What benefit would we gain? (Hint: The benefit would be great enough that we would be stupid to omit this mechanism.) (1 point)
For our example system, the bootstrap loader will also load a single root process, some interrupt and trap handlers, and a small set of servers. Most servers, however, will be launched by the root process as it reads and interprets the startup script.
For this problem, assume that your system has a keyboard, a high resolution video display and a local boot disk, but that it is not attached to any network.
Part A: What is the minimal set of servers that must be loaded by the bootstrap loader. For each server you list, give a sentence that justifies its inclusion in boot image. (2 points)
Part B: List several of the more important servers that you would expect the root process to launch as it reads the startup script. (2 points)
Part C: Taken together, the servers listed in parts A and B provide the foundation for the standard environment that user processes must be given by their creators at startup. Give a reasonable list of capabilities that should be in this environment. (Hint: Check your answer to question 2!) (2 points)
Part A: Give top-level pseudocode for the kernel's cache fault handler. (2 points)
Part B: Would allowing the general public to use the "lookup destination ID" service cause any security problems? (1 point)
Part C: There is a serious shortcoming of the kernel defined in the study questions! The registration server cannot find out the process ID and machine ID of the process attempting to register a destination ID. Suggest a change to the specifications for the kernel that would fix this. For full credit, your fix must not compromize the security of the system. (2 points)
Part D: A single registration server could lead to total system failure in the event of a single local failure. Outline the architecture of a fault tolerant registration server. (2 points)
When a user calls the "create process" service of the process manager, the process manager creates a process that is stopped and has no segments in its address space. It returns an owner capability for that process.
The Question: What operations must the owner capability for a process permit? (2 points)
Part A: Give a top-level outline of the structure of such a driver, clearly indicating which parts of the driver handle disk scheduling, which parts respond to what interrupts, where what queues are placed, and so on. (2 points)
Part B: How should the interrupt handler signal the server when it completes one of the requested disk I/O transfers. You cannot answer this question without reference to the specifics of the example system! (1 point)
Part C: Give details of the structure of each entry in the queue that is central to your solution to this question. (1 point)
Part D: The disk server has a fixed finite buffer capacity. What are the consequences of this, as seen by users? (2 points)